Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

U X e dUdX, e dX, cosine, secant, tangent, sine, 3.14159...


devel / comp.arch / Re: Another code compression idea

SubjectAuthor
* Another code compression ideaAnton Ertl
+* Re: Another code compression ideaMitchAlsup
|`* Re: Another code compression ideaAnton Ertl
| `* Re: Another code compression ideaIvan Godard
|  `* Re: Another code compression ideaAnton Ertl
|   `* Re: Another code compression ideaIvan Godard
|    +* Re: Another code compression ideaQuadibloc
|    |`* Re: Another code compression ideaThomas Koenig
|    | `- Re: Another code compression ideaIvan Godard
|    `- Re: Another code compression ideaBGB
+- Re: Another code compression ideaBill Findlay
+- Re: Another code compression ideaIvan Godard
+- Re: Another code compression ideaQuadibloc
+* Re: Another code compression ideaBrett
|+* Re: Another code compression ideaThomas Koenig
||`- Re: Another code compression ideaAnton Ertl
|+* Re: Another code compression ideaAnton Ertl
||`* Re: Another code compression ideaBrett
|| +* Re: Another code compression ideaMitchAlsup
|| |`- Re: Another code compression ideaMitchAlsup
|| `- Re: Another code compression ideaAnton Ertl
|`* Re: Another code compression ideaQuadibloc
| +* Re: Another code compression ideaAnton Ertl
| |+- Re: Another code compression ideaTerje Mathisen
| |`* Re: Another code compression ideaTimothy McCaffrey
| | `- Re: Another code compression ideaMitchAlsup
| +- Re: Another code compression ideaBGB
| `- Re: Another code compression ideaBrett
`* Re: Another code compression ideaTimothy McCaffrey
 `- Re: Another code compression ideaBrett

Pages:12
Re: Another code compression idea

<sr09ui$5sd$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=22731&group=comp.arch#22731

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ggt...@yahoo.com (Brett)
Newsgroups: comp.arch
Subject: Re: Another code compression idea
Date: Tue, 4 Jan 2022 02:04:03 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 102
Message-ID: <sr09ui$5sd$1@dont-email.me>
References: <2021Dec26.185955@mips.complang.tuwien.ac.at>
<ce81d71b-2edd-4b5a-915e-0954c6c0fdc3n@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 4 Jan 2022 02:04:03 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="30568d39d1faefed69e3e5523bc2f4e4";
logging-data="6029"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/YjkLVTXdftN1sFoOOzb4j"
User-Agent: NewsTap/5.5 (iPad)
Cancel-Lock: sha1:YpXR0AZWgSwS8Lu+hGLvUVUZhuo=
sha1:hp86IYtBLI0hz1MfXtfV7LBPQTY=
 by: Brett - Tue, 4 Jan 2022 02:04 UTC

Timothy McCaffrey <timcaffrey@aol.com> wrote:
> On Sunday, December 26, 2021 at 1:33:30 PM UTC-5, Anton Ertl wrote:
>> The RISC-V C (compressed) extension (and AFAIK Thumb and MIPS-16) work
>> by turning three-address instructions into two-address instructions,
>> reducing literal fields, and/or reducing the number of addressable
>> registers.
>>
>> Here's another idea: How about compressing by using the destination
>> register of the previous instruction as one of the sources?
>>
>> + Smaller code.
>>
>> + You directly know that you can forward from the previous instruction
>> to this one. And extending from this, you can directly encode stuff
>> for an ILDP architecture [kim&smith02].
>>
>> - The main disadvantage I see is that the meaning of the instructions
>> is not encoded just in itself. This is a problem when jumping to
>> such an instruction (just don't allow that, i.e., have an illegal
>> instruction exception if you jump to such an instruction). A bigger
>> problem is when there an interrupt or exception returns to such an
>> instruction; a way to deal with that may be to allow this encoding
>> only for instructions that cannot cause exceptions, and to delay
>> interrupts until the next self-contained instruction.
>>
>> @InProceedings{kim&smith02,
>> author = {Ho-Seop Kim and James E. Smith},
>> title = {An Instruction Set and Microarchitecture for
>> Instruction Level Distributed Processing},
>> crossref = {isca02},
>> pages = {71--81},
>> url = {http://www.ece.wisc.edu/~hskim/papers/kimh_ildp.pdf},
>> annote = {This paper addresses the problems of wide
>> superscalars with communication across the chip and
>> the number of write ports in the register file. The
>> authors propose an architecture (ILDP) with
>> general-purpose registers and with accumulators
>> (with instructions only accessing one accumulator
>> (read and/or write) and one register (read or
>> write); for the accumulators their death is
>> specified explicitly in the instructions. The
>> microarchitecture builds \emph{strands} from
>> instructions working on an accumulator; a strand
>> starts with an instruction writing to an accumulator
>> without reading from it, continues with instructions
>> reading from (and possibly writing to) the
>> accumulator and ends with an instruction that kills
>> the accumulator. Strands are allocated to one out of
>> eight processing elements (PEs) dynamically (i.e.,
>> accumulators are renamed). A PE consists of
>> mainly one ALU data path (but also a copy of the
>> GPRs and an L1 cache). They evaluated this
>> architecture by translating Alpha binaries into it,
>> and comparing their architecture to a 4-wide or
>> 8-wide Alpha implementation; their architecture has
>> a lower L1 cache latency, though. The performance of
>> ILDP in clock cycles is competetive, and one can
>> expect faster clocks for ILDP. The paper also
>> presents data for other stuff, e.g. general-purpose
>> register writes, which have to be promoted between
>> strands and which are relatively few.}
>> }
>>
>> @Proceedings{isca02,
>> title = "$29^\textit{th}$ Annual International Symposium on Computer Architecture",
>> booktitle = "$29^\textit{th}$ Annual International Symposium on Computer Architecture",
>> year = "2002",
>> key = "ISCA 29",
>> }
>>
>> - anton
>> --
>> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
>> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>
>
> You could just implement an expression stack. Keep the stack in your
> registers, have another register
> that points to "top of stack" in your register file. Normal stack
> expressions rarely exceed 8 levels.
> Lets see, then you could do:
> Z = A*Y + B*X
> load R1 <- A
> load R2 <- B
> load R3 <- X
> load R4 <- Y
> set tos to R30
> push R1 ;R30 = A
> MUL R4 ;R30 = A*Y
> push R2 ;R29 = B
> MUL R3 ;R20 = B*X
> ADD (tos, tos+1) ;R31 = A*Y+B*X
> store R31, Z
>
> This is an off the cuff answer, it seems like there are more efficient
> encodings than what I just came up with.
>
> - Tim
>

With the stack in registers you are 90% of the way to a belt, all you have
to do is disallow pops which you will because of the nightmares they cause
for scheduling.

Re: Another code compression idea

<srl495$luq$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=22921&group=comp.arch#22921

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ggt...@yahoo.com (Brett)
Newsgroups: comp.arch
Subject: Re: Another code compression idea
Date: Tue, 11 Jan 2022 23:36:05 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 58
Message-ID: <srl495$luq$1@dont-email.me>
References: <2021Dec26.185955@mips.complang.tuwien.ac.at>
<sqe61f$mid$1@dont-email.me>
<2021Dec28.115512@mips.complang.tuwien.ac.at>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 11 Jan 2022 23:36:05 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="6d7b51d35a70f64de1d8c9e270a995e9";
logging-data="22490"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19/Z9JAzMXFNt9HjuvLjZQg"
User-Agent: NewsTap/5.5 (iPad)
Cancel-Lock: sha1:GpjKrQXbQYy2TkHXZ86zYZf1Jc4=
sha1:ZEyobgU+UonK2c5ARE8sXlgRsHA=
 by: Brett - Tue, 11 Jan 2022 23:36 UTC

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Brett <ggtgp@yahoo.com> writes:
>> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> The RISC-V C (compressed) extension (and AFAIK Thumb and MIPS-16) work
>>> by turning three-address instructions into two-address instructions,
>>> reducing literal fields, and/or reducing the number of addressable
>>> registers.
>>>
>>> Here's another idea: How about compressing by using the destination
>>> register of the previous instruction as one of the sources?
>>>
>>> + Smaller code.
>>>
>>> + You directly know that you can forward from the previous instruction
>>> to this one. And extending from this, you can directly encode stuff
>>> for an ILDP architecture [kim&smith02].
>>
>> You just described a register plus accumulator design, the most well known
>> of which is the 8086
>
> Not quite. Architecturally the previous instruction still writes to
> any register (not just a specific one like on the 8086), and the
> current instruction reads from that register. Microarchitecturally,
> on a simple single-pipeline implementation you can see the forwarding
> as using an accumulator (the latch on the forwarding path), but you
> also get that when the current instruction names the register and it
> happens to be the same as the destination register of the previous
> instruction.
>
>> The biggest downside is you need byte sized instructions to get that good
>> code density, which hardware guys hate.
>
> It depends on what else you encode and how many registers you have. I
> was thinking about 16-bit instructions, as a replacement for RISC-V's
> compressed instructions. The benefit over those would be that you
> would have a free hand at selecting the other operand and the target;
> the cost would be that you could use this compression method only if
> the previous instruction writes to a source register of a current
> instruction.
>
>> The next step is deciding if you want a belt in front of your accumulator
>> so you can push two loads to ACC and then do an operation, a very common
>> occurrence.
>
> How common? I don't think it's common in most code I have written.

The start of every formula calculation has two loads.

A = (B + C) * D + whatever etc.

You load B and C first.

Makes sense to have at least a two position belt for your accumulator.

Of course one alternative is x86 add from memory…
I have promoted this in the past for better code density, but it is
justifiably hated by the hardware guys. ;)

Re: Another code compression idea

<9b2f7442-6bc4-450f-93df-67716f671708n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=22922&group=comp.arch#22922

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:622a:10a:: with SMTP id u10mr5926691qtw.323.1641945562409;
Tue, 11 Jan 2022 15:59:22 -0800 (PST)
X-Received: by 2002:a4a:d344:: with SMTP id d4mr638812oos.18.1641945562056;
Tue, 11 Jan 2022 15:59:22 -0800 (PST)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Tue, 11 Jan 2022 15:59:21 -0800 (PST)
In-Reply-To: <srl495$luq$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:48be:699a:8406:e0c8;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:48be:699a:8406:e0c8
References: <2021Dec26.185955@mips.complang.tuwien.ac.at> <sqe61f$mid$1@dont-email.me>
<2021Dec28.115512@mips.complang.tuwien.ac.at> <srl495$luq$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <9b2f7442-6bc4-450f-93df-67716f671708n@googlegroups.com>
Subject: Re: Another code compression idea
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Tue, 11 Jan 2022 23:59:22 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 79
 by: MitchAlsup - Tue, 11 Jan 2022 23:59 UTC

On Tuesday, January 11, 2022 at 5:36:08 PM UTC-6, gg...@yahoo.com wrote:
> Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> > Brett <gg...@yahoo.com> writes:
> >> Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> >>> The RISC-V C (compressed) extension (and AFAIK Thumb and MIPS-16) work
> >>> by turning three-address instructions into two-address instructions,
> >>> reducing literal fields, and/or reducing the number of addressable
> >>> registers.
> >>>
> >>> Here's another idea: How about compressing by using the destination
> >>> register of the previous instruction as one of the sources?
> >>>
> >>> + Smaller code.
> >>>
> >>> + You directly know that you can forward from the previous instruction
> >>> to this one. And extending from this, you can directly encode stuff
> >>> for an ILDP architecture [kim&smith02].
> >>
> >> You just described a register plus accumulator design, the most well known
> >> of which is the 8086
> >
> > Not quite. Architecturally the previous instruction still writes to
> > any register (not just a specific one like on the 8086), and the
> > current instruction reads from that register. Microarchitecturally,
> > on a simple single-pipeline implementation you can see the forwarding
> > as using an accumulator (the latch on the forwarding path), but you
> > also get that when the current instruction names the register and it
> > happens to be the same as the destination register of the previous
> > instruction.
> >
> >> The biggest downside is you need byte sized instructions to get that good
> >> code density, which hardware guys hate.
> >
> > It depends on what else you encode and how many registers you have. I
> > was thinking about 16-bit instructions, as a replacement for RISC-V's
> > compressed instructions. The benefit over those would be that you
> > would have a free hand at selecting the other operand and the target;
> > the cost would be that you could use this compression method only if
> > the previous instruction writes to a source register of a current
> > instruction.
> >
> >> The next step is deciding if you want a belt in front of your accumulator
> >> so you can push two loads to ACC and then do an operation, a very common
> >> occurrence.
> >
> > How common? I don't think it's common in most code I have written.
> The start of every formula calculation has two loads.
>
> A = (B + C) * D + whatever etc.
>
> You load B and C first.
<
What is one or the other was already in a register ?
>
> Makes sense to have at least a two position belt for your accumulator.
>
> Of course one alternative is x86 add from memory…
> I have promoted this in the past for better code density, but it is
> justifiably hated by the hardware guys. ;)
<
HW guys (like me) do not have a negative wrt LD-ops since the pipeline
cam be easily arranged such that inbound LDs which hit the cache appear
to have register latency. IBM 360 circa 1964, Gould 32/87, Interdata 32
<
Where we draw the line is Op-STs (and of course, LD-op-STs.) These
cannot be accommodated with straight pipeline design. However, once
you get to reservation station machines, it no longer matters.

Re: Another code compression idea

<113b744a-668c-466d-94ad-8b837eb81f89n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=22923&group=comp.arch#22923

 copy link   Newsgroups: comp.arch
X-Received: by 2002:ad4:5ba3:: with SMTP id 3mr6034711qvq.59.1641946316632;
Tue, 11 Jan 2022 16:11:56 -0800 (PST)
X-Received: by 2002:a05:6808:19a2:: with SMTP id bj34mr1591263oib.37.1641946316321;
Tue, 11 Jan 2022 16:11:56 -0800 (PST)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Tue, 11 Jan 2022 16:11:56 -0800 (PST)
In-Reply-To: <9b2f7442-6bc4-450f-93df-67716f671708n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:48be:699a:8406:e0c8;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:48be:699a:8406:e0c8
References: <2021Dec26.185955@mips.complang.tuwien.ac.at> <sqe61f$mid$1@dont-email.me>
<2021Dec28.115512@mips.complang.tuwien.ac.at> <srl495$luq$1@dont-email.me> <9b2f7442-6bc4-450f-93df-67716f671708n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <113b744a-668c-466d-94ad-8b837eb81f89n@googlegroups.com>
Subject: Re: Another code compression idea
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Wed, 12 Jan 2022 00:11:56 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 104
 by: MitchAlsup - Wed, 12 Jan 2022 00:11 UTC

On Tuesday, January 11, 2022 at 5:59:23 PM UTC-6, MitchAlsup wrote:
> On Tuesday, January 11, 2022 at 5:36:08 PM UTC-6, gg...@yahoo.com wrote:
> > Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> > > Brett <gg...@yahoo.com> writes:
> > >> Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> > >>> The RISC-V C (compressed) extension (and AFAIK Thumb and MIPS-16) work
> > >>> by turning three-address instructions into two-address instructions,
> > >>> reducing literal fields, and/or reducing the number of addressable
> > >>> registers.
> > >>>
> > >>> Here's another idea: How about compressing by using the destination
> > >>> register of the previous instruction as one of the sources?
> > >>>
> > >>> + Smaller code.
> > >>>
> > >>> + You directly know that you can forward from the previous instruction
> > >>> to this one. And extending from this, you can directly encode stuff
> > >>> for an ILDP architecture [kim&smith02].
> > >>
> > >> You just described a register plus accumulator design, the most well known
> > >> of which is the 8086
> > >
> > > Not quite. Architecturally the previous instruction still writes to
> > > any register (not just a specific one like on the 8086), and the
> > > current instruction reads from that register. Microarchitecturally,
> > > on a simple single-pipeline implementation you can see the forwarding
> > > as using an accumulator (the latch on the forwarding path), but you
> > > also get that when the current instruction names the register and it
> > > happens to be the same as the destination register of the previous
> > > instruction.
> > >
> > >> The biggest downside is you need byte sized instructions to get that good
> > >> code density, which hardware guys hate.
> > >
> > > It depends on what else you encode and how many registers you have. I
> > > was thinking about 16-bit instructions, as a replacement for RISC-V's
> > > compressed instructions. The benefit over those would be that you
> > > would have a free hand at selecting the other operand and the target;
> > > the cost would be that you could use this compression method only if
> > > the previous instruction writes to a source register of a current
> > > instruction.
> > >
> > >> The next step is deciding if you want a belt in front of your accumulator
> > >> so you can push two loads to ACC and then do an operation, a very common
> > >> occurrence.
> > >
> > > How common? I don't think it's common in most code I have written.
> > The start of every formula calculation has two loads.
> >
> > A = (B + C) * D + whatever etc.
> >
> > You load B and C first.
> <
> What is one or the other was already in a register ?
> >
> > Makes sense to have at least a two position belt for your accumulator.
> >
> > Of course one alternative is x86 add from memory…
> > I have promoted this in the past for better code density, but it is
> > justifiably hated by the hardware guys. ;)
> <
> HW guys (like me) do not have a negative wrt LD-ops since the pipeline
> cam be easily arranged such that inbound LDs which hit the cache appear
> to have register latency. IBM 360 circa 1964, Gould 32/87, Interdata 32
>
I think it is also fair to take issue with LD-ops--while one can configure
a pipeline to efficiently process LD-ops--the real question is should one
configure the ISA to support LD-ops (and/or ST-ops or even LD-op-STs.)
<
On this I take the position of no--but it is a fine balance between code
density and speed of execution: the former favoring -op-s the later
favoring individual instructions. Perhaps other pressures in the design
environment tip the balance differently than my current position.
<
Also note: it seems that My 66000 ISA is achieving code densities similar
to x86-64 in what smells (at first glance) as a pure RISC design (with
variable length instructions, and a few other tricks.)
<
> Where we draw the line is Op-STs (and of course, LD-op-STs.) These
> cannot be accommodated with straight pipeline design. However, once
> you get to reservation station machines, it no longer matters.

Re: Another code compression idea

<2022Jan13.184353@mips.complang.tuwien.ac.at>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=22948&group=comp.arch#22948

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.arch
Subject: Re: Another code compression idea
Date: Thu, 13 Jan 2022 17:43:53 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 49
Message-ID: <2022Jan13.184353@mips.complang.tuwien.ac.at>
References: <2021Dec26.185955@mips.complang.tuwien.ac.at> <sqe61f$mid$1@dont-email.me> <2021Dec28.115512@mips.complang.tuwien.ac.at> <srl495$luq$1@dont-email.me>
Injection-Info: reader02.eternal-september.org; posting-host="95c6cb72e378187266399e469428a698";
logging-data="24439"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/mKym0CKIlZf7qYUYf7qT9"
Cancel-Lock: sha1:lIo2yJgcZj/CHUAe5clGIQnehvg=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Thu, 13 Jan 2022 17:43 UTC

Brett <ggtgp@yahoo.com> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Brett <ggtgp@yahoo.com> writes:
>>> The next step is deciding if you want a belt in front of your accumulator
>>> so you can push two loads to ACC and then do an operation, a very common
>>> occurrence.
>>
>> How common? I don't think it's common in most code I have written.
>
>The start of every formula calculation has two loads.
>
>A = (B + C) * D + whatever etc.
>
>You load B and C first.

Reality check:

[~/tmp:127655] cat brett.c
long brett(long B, long C, long D, long whatever)
{ long A;
A = (B + C) * D + whatever;
return A;
} [~/tmp:127656] gcc -O -c brett.c
[~/tmp:127657] objdump -d brett.o

brett.o: file format elf64-x86-64

Disassembly of section .text:

0000000000000000 <brett>:
0: 48 01 f7 add %rsi,%rdi
3: 48 0f af fa imul %rdx,%rdi
7: 48 8d 04 0f lea (%rdi,%rcx,1),%rax
b: c3 retq

No loads to be seen here.

WRT my code compression idea, the second instruction takes the output
of the first as input, and the third takes the output of the second as
input. You also see the AMD64 output=input compression at work here
in the first and second instruction.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Pages:12
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor