Given recent very unfortunate news events, and the resulting sanctions
against Russia, I was looking up information on the capabilities Russia
has itself.
They can make chips down to 65nm, which is already enough to match
modern chips in speed. While China might be able to sell them the
chips it makes itself without U.S. technology, down to 14nm, it likely
would seek to keep all of those for its own military uses.
So I found out that their latest Elbrus chips use the same ISA as the
Elbrus 2000, although with some additions.
A complete spec of this architecture is apparently not available online.
However, I found some general information about it.
It is a VLIW architecture, but it's based on the SPARC, a RISC architecture.
A VLIW instruction is built from parts that are 16 and 32 bits in length.

This, so far, sounds like what I'm doing with Concertina, building up a
VLIW instruction out of RISC-like instructions.
But it differs in other ways.
The VLIW block begins with a short header that defines its layout.
All right, that sounds like the Itanium.
But the VLIW blocks are variable in length, and can be quite long or quite
short.

That makes me think of the VAX!

I recently came up with some more Concertina II ideas, aimed at minimizing
the overhead, and allowing instructions of different lengths to be partially
indicated in the simple 360-like way.
My initial thought, though, turned out to be impossible for reasons of
opcode space, but I eventually modified it - and it turned out to be
something that could be added to my current version of Concertina II
as only a minor change. Two non-predicated header block formats are
added, and the block format with predication will no longer allow pairs
of 16-bit instructions in a slot.

So that is likely to be coming up on my web site in a week or so.

John Savard

Quadibloc <jsavard@ecn.ab.ca> wrote:
> Given recent very unfortunate news events, and the resulting sanctions
> against Russia, I was looking up information on the capabilities Russia
> has itself.
> They can make chips down to 65nm, which is already enough to match
> modern chips in speed. While China might be able to sell them the
> chips it makes itself without U.S. technology, down to 14nm, it likely
> would seek to keep all of those for its own military uses.
> So I found out that their latest Elbrus chips use the same ISA as the
> Elbrus 2000, although with some additions.
> A complete spec of this architecture is apparently not available online.
> However, I found some general information about it.
> It is a VLIW architecture, but it's based on the SPARC, a RISC architecture.
> A VLIW instruction is built from parts that are 16 and 32 bits in length.

The current version is built in 28nm in Taiwan and clocks at 1.5GHz.
Up to 25 operations a cycle and has object descriptors for pointers.
Sounds like Mill…

Did you find an instruction set manual?

> This, so far, sounds like what I'm doing with Concertina, building up a
> VLIW instruction out of RISC-like instructions.
> But it differs in other ways.
> The VLIW block begins with a short header that defines its layout.
> All right, that sounds like the Itanium.
> But the VLIW blocks are variable in length, and can be quite long or quite
> short.
>
> That makes me think of the VAX!
>
> I recently came up with some more Concertina II ideas, aimed at minimizing
> the overhead, and allowing instructions of different lengths to be partially
> indicated in the simple 360-like way.
> My initial thought, though, turned out to be impossible for reasons of
> opcode space, but I eventually modified it - and it turned out to be
> something that could be added to my current version of Concertina II
> as only a minor change. Two non-predicated header block formats are
> added, and the block format with predication will no longer allow pairs
> of 16-bit instructions in a slot.
>
> So that is likely to be coming up on my web site in a week or so.
>
> John Savard
>

On Tuesday, April 12, 2022 at 5:24:13 PM UTC-6, gg...@yahoo.com wrote:

> The current version is built in 28nm in Taiwan and clocks at 1.5GHz.
> Up to 25 operations a cycle and has object descriptors for pointers.
> Sounds like Mill…

But they won't be able to get any more of those now.

> Did you find an instruction set manual?

No.

John Savard

On Monday, April 11, 2022 at 9:43:17 PM UTC-6, Quadibloc wrote:

> I recently came up with some more Concertina II ideas, aimed at minimizing
> the overhead, and allowing instructions of different lengths to be partially
> indicated in the simple 360-like way.
> My initial thought, though, turned out to be impossible for reasons of
> opcode space, but I eventually modified it - and it turned out to be
> something that could be added to my current version of Concertina II
> as only a minor change. Two non-predicated header block formats are
> added, and the block format with predication will no longer allow pairs
> of 16-bit instructions in a slot.
>
> So that is likely to be coming up on my web site in a week or so.

There isn't anything much to see yet, but I have now made the changeover
to the new architecture on the site, but only the first couple of pages are up.

Basically, what I've achieved this time is:

The block formats are simple. One version of the block has no header, the
three formats that do have headers are all fairly simple; one has a 16-bit
header, the other two have 32-bit headers.

Predication is possible, and instructions of different lengths are possible.

There is only one instruction set, but some of the instructions in it are not
available in all the modes. In some of my previous iterations, I had block
lengths where a modified version of the instruction set with some addressing
modes omitted was needed to make 32-bit instructions fit into half the opcode
space and things like that. This time, such things aren't needed.

Only 32-bit instructions are available in blocks without a header, and in
the blocks with a header that allows instructions to be predicated.

The format with a 16-bit header also allows 16-bit instructions.

Another format with a 32-bit header also allows instructions longer
than 32 bits, not counting immediates. Instructions may operate
on "pseudo-immediates", constant values that are placed in the instruction
stream, but not within the instruction itself, by being within the same 256-bit
block as the instruction, and being located by the use of a short pointer within
the instruction itself.

This pointer is about the same size as a register specification, making things
fit nicely.

Everything is arranged so that each individual instruction can be located by a
simple short and direct path after the 256-bit block is loaded into the CPU;
that way, all the instructions in a block can be rapidly decoded in parallel.

John Savard

Quadibloc <jsavard@ecn.ab.ca> wrote:
> On Tuesday, April 12, 2022 at 5:24:13 PM UTC-6, gg...@yahoo.com wrote:
>
>> The current version is built in 28nm in Taiwan and clocks at 1.5GHz.
>> Up to 25 operations a cycle and has object descriptors for pointers.
>> Sounds like Mill…
>
> But they won't be able to get any more of those now.
>
>> Did you find an instruction set manual?
>
> No.

Elbrus instruction set manual google translate link:

https://ftp-altlinux-org.translate.goog/pub/people/mike/elbrus/docs/elbrus_prog/html/?_x_tr_sch=http&_x_tr_sl=ru&_x_tr_tl=en&_x_tr_hl=en&_x_tr_pto=wapp

GitHub page which you should read first:

https://github.com/nrdmn/elbrus-docs

Brett <ggtgp@yahoo.com> wrote:
> Quadibloc <jsavard@ecn.ab.ca> wrote:
>> On Tuesday, April 12, 2022 at 5:24:13 PM UTC-6, gg...@yahoo.com wrote:
>>
>>> The current version is built in 28nm in Taiwan and clocks at 1.5GHz.
>>> Up to 25 operations a cycle and has object descriptors for pointers.
>>> Sounds like Mill…
>>
>> But they won't be able to get any more of those now.
>>
>>> Did you find an instruction set manual?
>>
>> No.
>
> Elbrus instruction set manual google translate link:
>
> https://ftp-altlinux-org.translate.goog/pub/people/mike/elbrus/docs/elbrus_prog/html/?_x_tr_sch=http&_x_tr_sl=ru&_x_tr_tl=en&_x_tr_hl=en&_x_tr_pto=wapp
>
> GitHub page which you should read first:
>
> https://github.com/nrdmn/elbrus-docs

So what do you think of Elbrus?
Wide execute variable width kinda of like Mill but no belt?

On Tuesday, April 19, 2022 at 6:45:31 PM UTC-5, gg...@yahoo.com wrote:
> Brett <gg...@yahoo.com> wrote:
> > Quadibloc <jsa...@ecn.ab.ca> wrote:
> >> On Tuesday, April 12, 2022 at 5:24:13 PM UTC-6, gg...@yahoo.com wrote:
> >>
> >>> The current version is built in 28nm in Taiwan and clocks at 1.5GHz.
> >>> Up to 25 operations a cycle and has object descriptors for pointers.
> >>> Sounds like Mill…
> >>
> >> But they won't be able to get any more of those now.
> >>
> >>> Did you find an instruction set manual?
> >>
> >> No.
> >
> > Elbrus instruction set manual google translate link:
> >
> > https://ftp-altlinux-org.translate.goog/pub/people/mike/elbrus/docs/elbrus_prog/html/?_x_tr_sch=http&_x_tr_sl=ru&_x_tr_tl=en&_x_tr_hl=en&_x_tr_pto=wapp
> >
> > GitHub page which you should read first:
> >
> > https://github.com/nrdmn/elbrus-docs
> So what do you think of Elbrus?
> Wide execute variable width kinda of like Mill but no belt?

Kinda supports my thesis of what will happen to computer architecture when register size goes
to 512 bits or more: Instruction register can hold an entire loop of instructions, data to and from
memory in similar size chunks. BTW at 1024 bits one "register" can capture an entire RISC CPU state
AKA register file.

More formally, would appear the Elbrus-2000 is an attempt, much like Itanium, an architectural variant
positioned to capture several trends discussed here and elsewhere.

On Tuesday, April 19, 2022 at 9:14:56 PM UTC-5, JimBrakefield wrote:
> On Tuesday, April 19, 2022 at 6:45:31 PM UTC-5, gg...@yahoo.com wrote:
> > Brett <gg...@yahoo.com> wrote:
> > > Quadibloc <jsa...@ecn.ab.ca> wrote:
> > >> On Tuesday, April 12, 2022 at 5:24:13 PM UTC-6, gg...@yahoo.com wrote:
> > >>
> > >>> The current version is built in 28nm in Taiwan and clocks at 1.5GHz..
> > >>> Up to 25 operations a cycle and has object descriptors for pointers..
> > >>> Sounds like Mill…
> > >>
> > >> But they won't be able to get any more of those now.
> > >>
> > >>> Did you find an instruction set manual?
> > >>
> > >> No.
> > >
> > > Elbrus instruction set manual google translate link:
> > >
> > > https://ftp-altlinux-org.translate.goog/pub/people/mike/elbrus/docs/elbrus_prog/html/?_x_tr_sch=http&_x_tr_sl=ru&_x_tr_tl=en&_x_tr_hl=en&_x_tr_pto=wapp
> > >
> > > GitHub page which you should read first:
> > >
> > > https://github.com/nrdmn/elbrus-docs
> > So what do you think of Elbrus?
> > Wide execute variable width kinda of like Mill but no belt?
> Kinda supports my thesis of what will happen to computer architecture when register size goes
> to 512 bits or more: Instruction register can hold an entire loop of instructions, data to and from
> memory in similar size chunks. BTW at 1024 bits one "register" can capture an entire RISC CPU state
> AKA register file.
<
Only one with 32 × 32-bit registers. Those with FP register files or those with 32 × 64-bit (or larger) registers
would not.
>
> More formally, would appear the Elbrus-2000 is an attempt, much like Itanium, an architectural variant
> positioned to capture several trends discussed here and elsewhere.
<
It might have seemed such in 1999 when I ran into it.

On 4/19/2022 9:14 PM, JimBrakefield wrote:
> On Tuesday, April 19, 2022 at 6:45:31 PM UTC-5, gg...@yahoo.com wrote:
>> Brett <gg...@yahoo.com> wrote:
>>> Quadibloc <jsa...@ecn.ab.ca> wrote:
>>>> On Tuesday, April 12, 2022 at 5:24:13 PM UTC-6, gg...@yahoo.com wrote:
>>>>
>>>>> The current version is built in 28nm in Taiwan and clocks at 1.5GHz.
>>>>> Up to 25 operations a cycle and has object descriptors for pointers.
>>>>> Sounds like Mill…
>>>>
>>>> But they won't be able to get any more of those now.
>>>>
>>>>> Did you find an instruction set manual?
>>>>
>>>> No.
>>>
>>> Elbrus instruction set manual google translate link:
>>>
>>> https://ftp-altlinux-org.translate.goog/pub/people/mike/elbrus/docs/elbrus_prog/html/?_x_tr_sch=http&_x_tr_sl=ru&_x_tr_tl=en&_x_tr_hl=en&_x_tr_pto=wapp
>>>
>>> GitHub page which you should read first:
>>>
>>> https://github.com/nrdmn/elbrus-docs
>> So what do you think of Elbrus?
>> Wide execute variable width kinda of like Mill but no belt?
>
> Kinda supports my thesis of what will happen to computer architecture when register size goes
> to 512 bits or more: Instruction register can hold an entire loop of instructions, data to and from
> memory in similar size chunks. BTW at 1024 bits one "register" can capture an entire RISC CPU state
> AKA register file.
>

FWIW: BJX2 GPR file is 4096 bits...

For huge registers, one is effectively either needing to run multiple
loop iterations in parallel, or running multiple logical threads in
lockstep (more like in a GPU).

> More formally, would appear the Elbrus-2000 is an attempt, much like Itanium, an architectural variant
> positioned to capture several trends discussed here and elsewhere.

Quite possibly.

One problem I have found is that, if one wants to go wider than 2 or 3,
the amount of "low hanging fruit" regarding ILP mostly evaporates. Only
reason 3 won out over 2 in my case was due to architectural subtleties,
not because of actually having enough usable ILP to justify this.

Though, even as such, Lane 3 is still sometimes useful, as a lot of
random ALU and shift ops may still end up here.

Similar issue occurs when making SIMD much larger than 128 bits.

GPR space size is a little more variable. Roughly 32 or 64 seems
optimal. There are some edge cases where 64 can offer an advantage over
32, but in most other contexts 64 is probably overkill.

OTOH, 6-bit register fields in a 32-bit instruction format is "kinda
painful"...

In my case, the normal encodings use 5-bit register fields, with only a
subset (or longer encodings) having 6-bit fields available. Attempts at
designs which tried to use 6-bit register fields directly suffered from
a lack of encoding space (and/or one also needs to drop most
immediate-form instructions to also use 6-bit immediate fields).

....

On Friday, 22 April 2022 at 19:01:00 UTC-7, BGB wrote:
> On 4/19/2022 9:14 PM, JimBrakefield wrote:
> > On Tuesday, April 19, 2022 at 6:45:31 PM UTC-5, gg...@yahoo.com wrote:
> >> Brett <gg...@yahoo.com> wrote:
> >>> Quadibloc <jsa...@ecn.ab.ca> wrote:
> >>>> On Tuesday, April 12, 2022 at 5:24:13 PM UTC-6, gg...@yahoo.com wrote:
> >>>>
> >>>>> The current version is built in 28nm in Taiwan and clocks at 1.5GHz..
> >>>>> Up to 25 operations a cycle and has object descriptors for pointers..
> >>>>> Sounds like Mill…
> >>>>
> >>>> But they won't be able to get any more of those now.
> >>>>
> >>>>> Did you find an instruction set manual?
> >>>>
> >>>> No.
> >>>
> >>> Elbrus instruction set manual google translate link:
> >>>
> >>> https://ftp-altlinux-org.translate.goog/pub/people/mike/elbrus/docs/elbrus_prog/html/?_x_tr_sch=http&_x_tr_sl=ru&_x_tr_tl=en&_x_tr_hl=en&_x_tr_pto=wapp
> >>>
> >>> GitHub page which you should read first:
> >>>
> >>> https://github.com/nrdmn/elbrus-docs
> >> So what do you think of Elbrus?
> >> Wide execute variable width kinda of like Mill but no belt?
> >
> > Kinda supports my thesis of what will happen to computer architecture when register size goes
> > to 512 bits or more: Instruction register can hold an entire loop of instructions, data to and from
> > memory in similar size chunks. BTW at 1024 bits one "register" can capture an entire RISC CPU state
> > AKA register file.
> >
> FWIW: BJX2 GPR file is 4096 bits...
>
> For huge registers, one is effectively either needing to run multiple
> loop iterations in parallel, or running multiple logical threads in
> lockstep (more like in a GPU).
> > More formally, would appear the Elbrus-2000 is an attempt, much like Itanium, an architectural variant
> > positioned to capture several trends discussed here and elsewhere.
> Quite possibly.
>
>
> One problem I have found is that, if one wants to go wider than 2 or 3,
> the amount of "low hanging fruit" regarding ILP mostly evaporates. Only
> reason 3 won out over 2 in my case was due to architectural subtleties,
> not because of actually having enough usable ILP to justify this.
>
> Though, even as such, Lane 3 is still sometimes useful, as a lot of
> random ALU and shift ops may still end up here.
>
>
> Similar issue occurs when making SIMD much larger than 128 bits.
>
> GPR space size is a little more variable. Roughly 32 or 64 seems
> optimal. There are some edge cases where 64 can offer an advantage over
> 32, but in most other contexts 64 is probably overkill.
>
>
> OTOH, 6-bit register fields in a 32-bit instruction format is "kinda
> painful"...
>
> In my case, the normal encodings use 5-bit register fields, with only a
> subset (or longer encodings) having 6-bit fields available. Attempts at
> designs which tried to use 6-bit register fields directly suffered from
> a lack of encoding space (and/or one also needs to drop most
> immediate-form instructions to also use 6-bit immediate fields).
>
> ...
DIRECT SENDER IS HERE LETS DEAL.

MT103/202 DIRECT WIRE TRANSFER
PAYPAL TRANSFER
CASHAPP TRANSFER
ZELLE TRANSFER
TRANSFER WISE
WESTERN UNION TRANSFER
BITCOIN FLASHING 
BANK ACCOUNT LOADING/FLASHING
IBAN TO IBAN TRANSFER
MONEYGRAM TRANSFER
IPIP/DTC
SLBC PROVIDER
CREDIT CARD TOP UP
DUMPS/ PINS
SEPA TRANSFER
WIRE TRANSFER
BITCOIN TOP UP
GLOBALPAY INC US
SKRILL USA

Thanks.

For more information Dm on WhatsApp:

+491512 9738176