On Thursday, June 24, 2021 at 8:55:02 AM UTC-5, BGB wrote:
> (Got distracted, posting got delayed...)
> On 6/22/2021 2:26 PM, MitchAlsup wrote:

> > <
> > I hope this is for better reasons than MIPS used in R2000 and R3000.....
> > <
> > R0 is the only register with HW defined use--and that is
> > a) gets IP return address when a CALL is performed
> > b) is an alias for IP when used as a base register
> > c) is an alias for zero when used as an index register
> > <
> > R31 (SP) has a bit that changes how ENTER and EXIT work
> > R30 (FP) has a bit that changes how ENTER and EXIT work.
<
> R0: May be stomped without warning if one tries to encode an operation
> with an immediate, and the immediate form can't otherwise be encoded for
> whatever reason.
<
I got rid of any need to stomp registers other than direct instructions.
So, My 66000 does not stomp any registers, it can supply immediates
of appropriate sizes.
>
> Say, assuming Jumbo isn't allowed:
> ADD R4, -9999, R6
> Might be encoded as if it were:
> MOV -9999, R0
> ADD R4, R0, R6
<
You are using instructions to build and deliver constants into the instruction stream.
>
> Also R0 and R1 are special cases for Load/Store encodings, ... So, can't
> be used as normal registers, since if the operation tries to use them as
> a base or index for a load, it invokes magic.
>
> Trying to branch to R0 or R1 may also invokes a few spacial cases:
> Branching to R0 is assumed to be an escaped absolute branch;
> Branching to R1 behaves as if it were an RTS using R1 as LR.
>
>
> R16 and R17 formally had similar restrictions, and were initially
> assumed unusable by the C ABI. However, in practice, they are normal
> GPRs. Generally they are treated as special-case scratch registers
> (along with R1).

On 6/24/2021 11:50 AM, MitchAlsup wrote:
> On Thursday, June 24, 2021 at 8:55:02 AM UTC-5, BGB wrote:
>> (Got distracted, posting got delayed...)
>> On 6/22/2021 2:26 PM, MitchAlsup wrote:
>
>>> <
>>> I hope this is for better reasons than MIPS used in R2000 and R3000.....
>>> <
>>> R0 is the only register with HW defined use--and that is
>>> a) gets IP return address when a CALL is performed
>>> b) is an alias for IP when used as a base register
>>> c) is an alias for zero when used as an index register
>>> <
>>> R31 (SP) has a bit that changes how ENTER and EXIT work
>>> R30 (FP) has a bit that changes how ENTER and EXIT work.
> <
>> R0: May be stomped without warning if one tries to encode an operation
>> with an immediate, and the immediate form can't otherwise be encoded for
>> whatever reason.
> <
> I got rid of any need to stomp registers other than direct instructions.
> So, My 66000 does not stomp any registers, it can supply immediates
> of appropriate sizes.

The original design was built around the assumption of register stomping
(for both R0 and R1).

With the ISA as it exists now, there is a lot less of it, but it still
exists as a possibility. The stomp register was made mostly off-limits
mostly because a "not off-limits" stomp register was super annoying in
its predecessors (SH and BJX1).

I moved the stuff that would have originally used R0 and R1 in the SH
ABI to use R2 and R3 in the BJX2 ABI.

R1 ends up being used a lot as a "secondary stomp register" by the
compiler, typically when generating an instruction sequence for a 3AC op
will require a temporary register (similar for R16 and R17).

But, since these aren't really allowed as memory base or displacements,
some built-in ops (such as memory copies) need to use the other scratch
registers, which then blows the function's status as a "pure leaf" (so
it creates a stack frame and uses the old register allocator).

At present, the "pure leaf" status also excludes functions containing
floating point and vector types, but this may change later.

>>
>> Say, assuming Jumbo isn't allowed:
>> ADD R4, -9999, R6
>> Might be encoded as if it were:
>> MOV -9999, R0
>> ADD R4, R0, R6
> <
> You are using instructions to build and deliver constants into the instruction stream.

As noted, "assuming Jumbo isn't allowed".

If Jumbo is allowed, this case can be in-effect encoded as a single
instruction.

Jumbo isn't always allowed though:
It is still an optional feature as far as the ISA is concerned:
Lite profile cores are allowed to omit it (1).

*1: The Lite profile may differ in a few ways:
Scalar only;
16/32 bit ops only;
Jumbo is optional (*2);
FPU and MMU are optional;
No 128-bit operations;
Uses a smaller address space
32-bit physical, split into a 30-bit (RAM) and 28-bit region (MMIO).

This is mostly to make it viable to use on the XC7S25 and similar (or
potentially also various ECP5 devices or similar). Granted, in this area
it would face more competition against RISC-V or similar.

*2: There is a mechanism to allow Jumbo to be used, but internally it
functions as multiple logical 32-bit instructions with a decoding hack.
Pipeline registers are used to implement the jumbo-op decoding, with the
prefix itself decoding as a NOP.

Jumbo isn't generally used in many cases if the code is being generated
to be used by the wexifier, since jumbo encodings are currently treated
as immovable by the wexifier and can't currently be parallelized. Fixing
this would likely require redesigning the wexifier.

So, at the moment, the wexifier can only deal with 32-bit encodings, and
the example op would require a 64-bit encoding to be expressed directly.

Note that using a jumbo encoding here doesn't actually break anything,
but in this case, it turned out on-average it was better for performance
in this case to load the value into a register and then do an operation
on it separately, since this more often allows running one or both
operations in parallel with another instruction.

The exception is for cases where a constant load would itself be require
a jumbo encoding, in which case it is better to "bite the bullet" here,
so (Immed Bits):
0..9: Single Op (32-bit);
10..16: Better to split into two ops;
17+: Better to use a jumbo encoding.

>>
>> Also R0 and R1 are special cases for Load/Store encodings, ... So, can't
>> be used as normal registers, since if the operation tries to use them as
>> a base or index for a load, it invokes magic.
>>
>> Trying to branch to R0 or R1 may also invokes a few spacial cases:
>> Branching to R0 is assumed to be an escaped absolute branch;
>> Branching to R1 behaves as if it were an RTS using R1 as LR.
>>
>>
>> R16 and R17 formally had similar restrictions, and were initially
>> assumed unusable by the C ABI. However, in practice, they are normal
>> GPRs. Generally they are treated as special-case scratch registers
>> (along with R1).

On Thursday, June 24, 2021 at 12:49:14 PM UTC-5, BGB wrote:
> On 6/24/2021 11:50 AM, MitchAlsup wrote:
> > On Thursday, June 24, 2021 at 8:55:02 AM UTC-5, BGB wrote:
> >> (Got distracted, posting got delayed...)
> >> On 6/22/2021 2:26 PM, MitchAlsup wrote:
> >
> >>> <
> >>> I hope this is for better reasons than MIPS used in R2000 and R3000.....
> >>> <
> >>> R0 is the only register with HW defined use--and that is
> >>> a) gets IP return address when a CALL is performed
> >>> b) is an alias for IP when used as a base register
> >>> c) is an alias for zero when used as an index register
> >>> <
> >>> R31 (SP) has a bit that changes how ENTER and EXIT work
> >>> R30 (FP) has a bit that changes how ENTER and EXIT work.
> > <
> >> R0: May be stomped without warning if one tries to encode an operation
> >> with an immediate, and the immediate form can't otherwise be encoded for
> >> whatever reason.
> > <
> > I got rid of any need to stomp registers other than direct instructions.
> > So, My 66000 does not stomp any registers, it can supply immediates
> > of appropriate sizes.
> The original design was built around the assumption of register stomping
> (for both R0 and R1).
>
> With the ISA as it exists now, there is a lot less of it, but it still
> exists as a possibility. The stomp register was made mostly off-limits
> mostly because a "not off-limits" stomp register was super annoying in
> its predecessors (SH and BJX1).
>
> I moved the stuff that would have originally used R0 and R1 in the SH
> ABI to use R2 and R3 in the BJX2 ABI.
>
>
> R1 ends up being used a lot as a "secondary stomp register" by the
> compiler, typically when generating an instruction sequence for a 3AC op
> will require a temporary register (similar for R16 and R17).
>
> But, since these aren't really allowed as memory base or displacements,
> some built-in ops (such as memory copies) need to use the other scratch
> registers, which then blows the function's status as a "pure leaf" (so
> it creates a stack frame and uses the old register allocator).
>
> At present, the "pure leaf" status also excludes functions containing
> floating point and vector types, but this may change later.
> >>
> >> Say, assuming Jumbo isn't allowed:
> >> ADD R4, -9999, R6
> >> Might be encoded as if it were:
> >> MOV -9999, R0
> >> ADD R4, R0, R6
> > <
> > You are using instructions to build and deliver constants into the instruction stream.
> As noted, "assuming Jumbo isn't allowed".
>
> If Jumbo is allowed, this case can be in-effect encoded as a single
> instruction.
>
>
> Jumbo isn't always allowed though:
> It is still an optional feature as far as the ISA is concerned:
> Lite profile cores are allowed to omit it (1).
<
This is a choice bordering on the poor end of the spectrum of choices.
>
>
> *1: The Lite profile may differ in a few ways:
> Scalar only;
> 16/32 bit ops only;
> Jumbo is optional (*2);
<
Note: Even VVM is mandatory in My 66000--but VVM can be performed on
a 1-wide in-order machine with no extra circuits other than a VVM sequencer.
<
> FPU and MMU are optional;
<
Bad choice:: My 66000 does not even come out of reset with the MMU turned off !!
Even I/O is defined to pass through an I/O MMU.
<
I would not design an ISA these days, with available gate counts, that does not
have FP built in.
<
> No 128-bit operations;
<
All access to multi-precision stuff is through CARRY in My 66000. CARRY
is not optional, but it is only a couple of sequences on low end processors.
<
> Uses a smaller address space
> 32-bit physical, split into a 30-bit (RAM) and 28-bit region (MMIO).
<
I control this through the <non optional> MMU. The programmer sees
either a 32-bit virtual address space or a 64-bit virtual address space.
Either of which may see a 40-bit-to-64-bit physical address space.
>
> This is mostly to make it viable to use on the XC7S25 and similar (or
> potentially also various ECP5 devices or similar). Granted, in this area
> it would face more competition against RISC-V or similar.
>
I am aware of your implementation limitations.
>

On 6/24/2021 1:44 PM, MitchAlsup wrote:
> On Thursday, June 24, 2021 at 12:49:14 PM UTC-5, BGB wrote:
>> On 6/24/2021 11:50 AM, MitchAlsup wrote:
>>> On Thursday, June 24, 2021 at 8:55:02 AM UTC-5, BGB wrote:
>>>> (Got distracted, posting got delayed...)
>>>> On 6/22/2021 2:26 PM, MitchAlsup wrote:
>>>
>>>>> <
>>>>> I hope this is for better reasons than MIPS used in R2000 and R3000.....
>>>>> <
>>>>> R0 is the only register with HW defined use--and that is
>>>>> a) gets IP return address when a CALL is performed
>>>>> b) is an alias for IP when used as a base register
>>>>> c) is an alias for zero when used as an index register
>>>>> <
>>>>> R31 (SP) has a bit that changes how ENTER and EXIT work
>>>>> R30 (FP) has a bit that changes how ENTER and EXIT work.
>>> <
>>>> R0: May be stomped without warning if one tries to encode an operation
>>>> with an immediate, and the immediate form can't otherwise be encoded for
>>>> whatever reason.
>>> <
>>> I got rid of any need to stomp registers other than direct instructions.
>>> So, My 66000 does not stomp any registers, it can supply immediates
>>> of appropriate sizes.
>> The original design was built around the assumption of register stomping
>> (for both R0 and R1).
>>
>> With the ISA as it exists now, there is a lot less of it, but it still
>> exists as a possibility. The stomp register was made mostly off-limits
>> mostly because a "not off-limits" stomp register was super annoying in
>> its predecessors (SH and BJX1).
>>
>> I moved the stuff that would have originally used R0 and R1 in the SH
>> ABI to use R2 and R3 in the BJX2 ABI.
>>
>>
>> R1 ends up being used a lot as a "secondary stomp register" by the
>> compiler, typically when generating an instruction sequence for a 3AC op
>> will require a temporary register (similar for R16 and R17).
>>
>> But, since these aren't really allowed as memory base or displacements,
>> some built-in ops (such as memory copies) need to use the other scratch
>> registers, which then blows the function's status as a "pure leaf" (so
>> it creates a stack frame and uses the old register allocator).
>>
>> At present, the "pure leaf" status also excludes functions containing
>> floating point and vector types, but this may change later.
>>>>
>>>> Say, assuming Jumbo isn't allowed:
>>>> ADD R4, -9999, R6
>>>> Might be encoded as if it were:
>>>> MOV -9999, R0
>>>> ADD R4, R0, R6
>>> <
>>> You are using instructions to build and deliver constants into the instruction stream.
>> As noted, "assuming Jumbo isn't allowed".
>>
>> If Jumbo is allowed, this case can be in-effect encoded as a single
>> instruction.
>>
>>
>> Jumbo isn't always allowed though:
>> It is still an optional feature as far as the ISA is concerned:
>> Lite profile cores are allowed to omit it (1).
> <
> This is a choice bordering on the poor end of the spectrum of choices.
>>
>>
>> *1: The Lite profile may differ in a few ways:
>> Scalar only;
>> 16/32 bit ops only;
>> Jumbo is optional (*2);
> <
> Note: Even VVM is mandatory in My 66000--but VVM can be performed on
> a 1-wide in-order machine with no extra circuits other than a VVM sequencer.
> <
>> FPU and MMU are optional;
> <
> Bad choice:: My 66000 does not even come out of reset with the MMU turned off !!
> Even I/O is defined to pass through an I/O MMU.

The FPU and MMU are required for the Full profile, but not for the Lite
profile.

The Lite profile is intended more for use as a microcontroller, and
these profiles are not required to be binary compatible.

Granted, potentially a MMU could stretch KB of RAM a little further, if
one is implementing virtual memory onto an SDcard or similar. Though,
even 4K pages are a pretty coarse granularity when the RAM is in KB
territory.

Though it could almost make sense in this case to try devising some sort
of "Use SDcard like non-volatile RAM" mechanism (or externally wire up a
QSPI SRAM module or similar).

An FPU is kinda expensive, and not really needed in a microcontroller.

> <
> I would not design an ISA these days, with available gate counts, that does not
> have FP built in.
> <

The FPU exists in the Full profile, just it is a bit of a stretch on the
smaller FPGAs.

Similarly, the MMU adds a lot of cost for a small scalar core, and one
might want to, say, try to keep their core under 10k LUTs so that they
can have some space left for IO devices and similar.

>> No 128-bit operations;
> <
> All access to multi-precision stuff is through CARRY in My 66000. CARRY
> is not optional, but it is only a couple of sequences on low end processors.
> <

This mostly covers MOV.X and 128-bit SIMD, which as-implemented require
multiple lanes. On a Lite core it needs to be broken up into MOV.Q ops.

>> Uses a smaller address space
>> 32-bit physical, split into a 30-bit (RAM) and 28-bit region (MMIO).
> <
> I control this through the <non optional> MMU. The programmer sees
> either a 32-bit virtual address space or a 64-bit virtual address space.
> Either of which may see a 40-bit-to-64-bit physical address space.

Currently, it is 32-bit in Lite, 48 bit in Full.

The current physical space is a 30-bit RAM space:
0000_0000 .. 3FFF_FFFF
And, 28-bit MMIO space:
F000_0000 .. FFFF_FFFF

Could support a bigger physical space, but none of the FPGA boards I
have, have enough RAM to make this worthwhile.

For now, RAM generally goes into the area:
0100_0000 .. 07FF_FFFF

On the CMod-S7 I have, it puts its RAM space into:
0100_0000 .. 0101_FFFF

In this case, the L2 cache functions as RAM, because there is no
external RAM on this board.

Another (slightly more expensive) version of the CMod board had a 512K
RAM module though, but the board I got didn't have any RAM.

>>
>> This is mostly to make it viable to use on the XC7S25 and similar (or
>> potentially also various ECP5 devices or similar). Granted, in this area
>> it would face more competition against RISC-V or similar.
>>
> I am aware of your implementation limitations.

As can be noted though, I am mostly targeting the XC7A100...

But, the XC7S25 is more limited than the XC7A100, as are most of the
ECP5 chips.

The ECP5's can have a decent number of LUTs, but are a little more
limited in that it is built around LUT4's.

There is also ICE40, but there is little hope of fitting a BJX2 core
onto an ICE40. For the most part, people are doing 8/16 designs on ICE40
though.

Though, one can argue though that even on the lower-end, the FPGAs still
aren't particularly cost-competitive with a Teensy or Pi Pico or
similar... But, can have more powerful IO.

On Friday, June 25, 2021 at 12:49:03 AM UTC+3, BGB wrote:
> On 6/24/2021 1:44 PM, MitchAlsup wrote:
> > On Thursday, June 24, 2021 at 12:49:14 PM UTC-5, BGB wrote:
> >> On 6/24/2021 11:50 AM, MitchAlsup wrote:
> >>> On Thursday, June 24, 2021 at 8:55:02 AM UTC-5, BGB wrote:
> >>>> (Got distracted, posting got delayed...)
> >>>> On 6/22/2021 2:26 PM, MitchAlsup wrote:
> >>>
> >>>>> <
> >>>>> I hope this is for better reasons than MIPS used in R2000 and R3000.....
> >>>>> <
> >>>>> R0 is the only register with HW defined use--and that is
> >>>>> a) gets IP return address when a CALL is performed
> >>>>> b) is an alias for IP when used as a base register
> >>>>> c) is an alias for zero when used as an index register
> >>>>> <
> >>>>> R31 (SP) has a bit that changes how ENTER and EXIT work
> >>>>> R30 (FP) has a bit that changes how ENTER and EXIT work.
> >>> <
> >>>> R0: May be stomped without warning if one tries to encode an operation
> >>>> with an immediate, and the immediate form can't otherwise be encoded for
> >>>> whatever reason.
> >>> <
> >>> I got rid of any need to stomp registers other than direct instructions.
> >>> So, My 66000 does not stomp any registers, it can supply immediates
> >>> of appropriate sizes.
> >> The original design was built around the assumption of register stomping
> >> (for both R0 and R1).
> >>
> >> With the ISA as it exists now, there is a lot less of it, but it still
> >> exists as a possibility. The stomp register was made mostly off-limits
> >> mostly because a "not off-limits" stomp register was super annoying in
> >> its predecessors (SH and BJX1).
> >>
> >> I moved the stuff that would have originally used R0 and R1 in the SH
> >> ABI to use R2 and R3 in the BJX2 ABI.
> >>
> >>
> >> R1 ends up being used a lot as a "secondary stomp register" by the
> >> compiler, typically when generating an instruction sequence for a 3AC op
> >> will require a temporary register (similar for R16 and R17).
> >>
> >> But, since these aren't really allowed as memory base or displacements,
> >> some built-in ops (such as memory copies) need to use the other scratch
> >> registers, which then blows the function's status as a "pure leaf" (so
> >> it creates a stack frame and uses the old register allocator).
> >>
> >> At present, the "pure leaf" status also excludes functions containing
> >> floating point and vector types, but this may change later.
> >>>>
> >>>> Say, assuming Jumbo isn't allowed:
> >>>> ADD R4, -9999, R6
> >>>> Might be encoded as if it were:
> >>>> MOV -9999, R0
> >>>> ADD R4, R0, R6
> >>> <
> >>> You are using instructions to build and deliver constants into the instruction stream.
> >> As noted, "assuming Jumbo isn't allowed".
> >>
> >> If Jumbo is allowed, this case can be in-effect encoded as a single
> >> instruction.
> >>
> >>
> >> Jumbo isn't always allowed though:
> >> It is still an optional feature as far as the ISA is concerned:
> >> Lite profile cores are allowed to omit it (1).
> > <
> > This is a choice bordering on the poor end of the spectrum of choices.
> >>
> >>
> >> *1: The Lite profile may differ in a few ways:
> >> Scalar only;
> >> 16/32 bit ops only;
> >> Jumbo is optional (*2);
> > <
> > Note: Even VVM is mandatory in My 66000--but VVM can be performed on
> > a 1-wide in-order machine with no extra circuits other than a VVM sequencer.
> > <
> >> FPU and MMU are optional;
> > <
> > Bad choice:: My 66000 does not even come out of reset with the MMU turned off !!
> > Even I/O is defined to pass through an I/O MMU.
> The FPU and MMU are required for the Full profile, but not for the Lite
> profile.
>
> The Lite profile is intended more for use as a microcontroller, and
> these profiles are not required to be binary compatible.
>
>
> Granted, potentially a MMU could stretch KB of RAM a little further, if
> one is implementing virtual memory onto an SDcard or similar. Though,
> even 4K pages are a pretty coarse granularity when the RAM is in KB
> territory.
>
> Though it could almost make sense in this case to try devising some sort
> of "Use SDcard like non-volatile RAM" mechanism (or externally wire up a
> QSPI SRAM module or similar).
>
>
> An FPU is kinda expensive, and not really needed in a microcontroller.
> > <
> > I would not design an ISA these days, with available gate counts, that does not
> > have FP built in.
> > <
> The FPU exists in the Full profile, just it is a bit of a stretch on the
> smaller FPGAs.
>
> Similarly, the MMU adds a lot of cost for a small scalar core, and one
> might want to, say, try to keep their core under 10k LUTs so that they
> can have some space left for IO devices and similar.
> >> No 128-bit operations;
> > <
> > All access to multi-precision stuff is through CARRY in My 66000. CARRY
> > is not optional, but it is only a couple of sequences on low end processors.
> > <
> This mostly covers MOV.X and 128-bit SIMD, which as-implemented require
> multiple lanes. On a Lite core it needs to be broken up into MOV.Q ops.
> >> Uses a smaller address space
> >> 32-bit physical, split into a 30-bit (RAM) and 28-bit region (MMIO).
> > <
> > I control this through the <non optional> MMU. The programmer sees
> > either a 32-bit virtual address space or a 64-bit virtual address space.
> > Either of which may see a 40-bit-to-64-bit physical address space.
> Currently, it is 32-bit in Lite, 48 bit in Full.
>
> The current physical space is a 30-bit RAM space:
> 0000_0000 .. 3FFF_FFFF
> And, 28-bit MMIO space:
> F000_0000 .. FFFF_FFFF
>
> Could support a bigger physical space, but none of the FPGA boards I
> have, have enough RAM to make this worthwhile.
>
> For now, RAM generally goes into the area:
> 0100_0000 .. 07FF_FFFF
>
>
> On the CMod-S7 I have, it puts its RAM space into:
> 0100_0000 .. 0101_FFFF
>
> In this case, the L2 cache functions as RAM, because there is no
> external RAM on this board.
>
> Another (slightly more expensive) version of the CMod board had a 512K
> RAM module though, but the board I got didn't have any RAM.
> >>
> >> This is mostly to make it viable to use on the XC7S25 and similar (or
> >> potentially also various ECP5 devices or similar). Granted, in this area
> >> it would face more competition against RISC-V or similar.
> >>
> > I am aware of your implementation limitations.
> As can be noted though, I am mostly targeting the XC7A100...
>
>
> But, the XC7S25 is more limited than the XC7A100, as are most of the
> ECP5 chips.
>
> The ECP5's can have a decent number of LUTs, but are a little more
> limited in that it is built around LUT4's.
>
> There is also ICE40, but there is little hope of fitting a BJX2 core
> onto an ICE40. For the most part, people are doing 8/16 designs on ICE40
> though.
>

I have no idea who are "people" you are talking about. Would think that most of them are enthusiasts rather than pros.

Me, being a pro, I very much prefer 32-bit soft cores, supported by standard compilers (in practice it means gcc).
For convenience of reliable tools I am fully willing to a cost of pretty low MIPS/MHz, which would be typical for
resource-constrained implementation of such core.
In particular, I often use Nios2e core that gives ~0.15 MIPS/MHz, fits in ~600 4-input LUTs + 2 Embedded memory banks
and hits pretty high frequencies. I would guess, that at your XC7A100 it will be close to 200MHz.
core like that fits with ease within iCE5LP4K and for some less logic-intensive apps can be useful even in iCE5LP2K.

Of course, Nios2 is property of Altera/Intel and (IANAAL) most likely can't be legally used on Lattice devices.
But it's extremly similar to fixed-width variant of RV32 which is certainly legal to use everywhere.

On 6/25/2021 4:55 AM, Michael S wrote:
> On Friday, June 25, 2021 at 12:49:03 AM UTC+3, BGB wrote:
>> On 6/24/2021 1:44 PM, MitchAlsup wrote:
>>> On Thursday, June 24, 2021 at 12:49:14 PM UTC-5, BGB wrote:
>>>> On 6/24/2021 11:50 AM, MitchAlsup wrote:
>>>>> On Thursday, June 24, 2021 at 8:55:02 AM UTC-5, BGB wrote:
>>>>>> (Got distracted, posting got delayed...)
>>>>>> On 6/22/2021 2:26 PM, MitchAlsup wrote:
>>>>>
>>>>>>> <
>>>>>>> I hope this is for better reasons than MIPS used in R2000 and R3000.....
>>>>>>> <
>>>>>>> R0 is the only register with HW defined use--and that is
>>>>>>> a) gets IP return address when a CALL is performed
>>>>>>> b) is an alias for IP when used as a base register
>>>>>>> c) is an alias for zero when used as an index register
>>>>>>> <
>>>>>>> R31 (SP) has a bit that changes how ENTER and EXIT work
>>>>>>> R30 (FP) has a bit that changes how ENTER and EXIT work.
>>>>> <
>>>>>> R0: May be stomped without warning if one tries to encode an operation
>>>>>> with an immediate, and the immediate form can't otherwise be encoded for
>>>>>> whatever reason.
>>>>> <
>>>>> I got rid of any need to stomp registers other than direct instructions.
>>>>> So, My 66000 does not stomp any registers, it can supply immediates
>>>>> of appropriate sizes.
>>>> The original design was built around the assumption of register stomping
>>>> (for both R0 and R1).
>>>>
>>>> With the ISA as it exists now, there is a lot less of it, but it still
>>>> exists as a possibility. The stomp register was made mostly off-limits
>>>> mostly because a "not off-limits" stomp register was super annoying in
>>>> its predecessors (SH and BJX1).
>>>>
>>>> I moved the stuff that would have originally used R0 and R1 in the SH
>>>> ABI to use R2 and R3 in the BJX2 ABI.
>>>>
>>>>
>>>> R1 ends up being used a lot as a "secondary stomp register" by the
>>>> compiler, typically when generating an instruction sequence for a 3AC op
>>>> will require a temporary register (similar for R16 and R17).
>>>>
>>>> But, since these aren't really allowed as memory base or displacements,
>>>> some built-in ops (such as memory copies) need to use the other scratch
>>>> registers, which then blows the function's status as a "pure leaf" (so
>>>> it creates a stack frame and uses the old register allocator).
>>>>
>>>> At present, the "pure leaf" status also excludes functions containing
>>>> floating point and vector types, but this may change later.
>>>>>>
>>>>>> Say, assuming Jumbo isn't allowed:
>>>>>> ADD R4, -9999, R6
>>>>>> Might be encoded as if it were:
>>>>>> MOV -9999, R0
>>>>>> ADD R4, R0, R6
>>>>> <
>>>>> You are using instructions to build and deliver constants into the instruction stream.
>>>> As noted, "assuming Jumbo isn't allowed".
>>>>
>>>> If Jumbo is allowed, this case can be in-effect encoded as a single
>>>> instruction.
>>>>
>>>>
>>>> Jumbo isn't always allowed though:
>>>> It is still an optional feature as far as the ISA is concerned:
>>>> Lite profile cores are allowed to omit it (1).
>>> <
>>> This is a choice bordering on the poor end of the spectrum of choices.
>>>>
>>>>
>>>> *1: The Lite profile may differ in a few ways:
>>>> Scalar only;
>>>> 16/32 bit ops only;
>>>> Jumbo is optional (*2);
>>> <
>>> Note: Even VVM is mandatory in My 66000--but VVM can be performed on
>>> a 1-wide in-order machine with no extra circuits other than a VVM sequencer.
>>> <
>>>> FPU and MMU are optional;
>>> <
>>> Bad choice:: My 66000 does not even come out of reset with the MMU turned off !!
>>> Even I/O is defined to pass through an I/O MMU.
>> The FPU and MMU are required for the Full profile, but not for the Lite
>> profile.
>>
>> The Lite profile is intended more for use as a microcontroller, and
>> these profiles are not required to be binary compatible.
>>
>>
>> Granted, potentially a MMU could stretch KB of RAM a little further, if
>> one is implementing virtual memory onto an SDcard or similar. Though,
>> even 4K pages are a pretty coarse granularity when the RAM is in KB
>> territory.
>>
>> Though it could almost make sense in this case to try devising some sort
>> of "Use SDcard like non-volatile RAM" mechanism (or externally wire up a
>> QSPI SRAM module or similar).
>>
>>
>> An FPU is kinda expensive, and not really needed in a microcontroller.
>>> <
>>> I would not design an ISA these days, with available gate counts, that does not
>>> have FP built in.
>>> <
>> The FPU exists in the Full profile, just it is a bit of a stretch on the
>> smaller FPGAs.
>>
>> Similarly, the MMU adds a lot of cost for a small scalar core, and one
>> might want to, say, try to keep their core under 10k LUTs so that they
>> can have some space left for IO devices and similar.
>>>> No 128-bit operations;
>>> <
>>> All access to multi-precision stuff is through CARRY in My 66000. CARRY
>>> is not optional, but it is only a couple of sequences on low end processors.
>>> <
>> This mostly covers MOV.X and 128-bit SIMD, which as-implemented require
>> multiple lanes. On a Lite core it needs to be broken up into MOV.Q ops.
>>>> Uses a smaller address space
>>>> 32-bit physical, split into a 30-bit (RAM) and 28-bit region (MMIO).
>>> <
>>> I control this through the <non optional> MMU. The programmer sees
>>> either a 32-bit virtual address space or a 64-bit virtual address space.
>>> Either of which may see a 40-bit-to-64-bit physical address space.
>> Currently, it is 32-bit in Lite, 48 bit in Full.
>>
>> The current physical space is a 30-bit RAM space:
>> 0000_0000 .. 3FFF_FFFF
>> And, 28-bit MMIO space:
>> F000_0000 .. FFFF_FFFF
>>
>> Could support a bigger physical space, but none of the FPGA boards I
>> have, have enough RAM to make this worthwhile.
>>
>> For now, RAM generally goes into the area:
>> 0100_0000 .. 07FF_FFFF
>>
>>
>> On the CMod-S7 I have, it puts its RAM space into:
>> 0100_0000 .. 0101_FFFF
>>
>> In this case, the L2 cache functions as RAM, because there is no
>> external RAM on this board.
>>
>> Another (slightly more expensive) version of the CMod board had a 512K
>> RAM module though, but the board I got didn't have any RAM.
>>>>
>>>> This is mostly to make it viable to use on the XC7S25 and similar (or
>>>> potentially also various ECP5 devices or similar). Granted, in this area
>>>> it would face more competition against RISC-V or similar.
>>>>
>>> I am aware of your implementation limitations.
>> As can be noted though, I am mostly targeting the XC7A100...
>>
>>
>> But, the XC7S25 is more limited than the XC7A100, as are most of the
>> ECP5 chips.
>>
>> The ECP5's can have a decent number of LUTs, but are a little more
>> limited in that it is built around LUT4's.
>>
>> There is also ICE40, but there is little hope of fitting a BJX2 core
>> onto an ICE40. For the most part, people are doing 8/16 designs on ICE40
>> though.
>>
>
> I have no idea who are "people" you are talking about. Would think that most of them are enthusiasts rather than pros.
>

Possibly.

I noted this when doing web searches on the subject in the past.

Things like 6502 and 8080 / Z80 clones and similar seem to be popular, ...

There are a few 32 bit cores as well though, ...

Granted, even for non FPGA stuff, one semi-popular project (the
"Commander X16"), initially went with a 65C816 (and has since apparently
gone to the 65C02).

BGB <cr88192@gmail.com> writes:
>Likely, A64 could be a little better here, but is hindered mostly by a
>general lack of usable 64-bit builds of Raspbian and similar.

[raspi4:~:72386] cat /proc/cpuinfo
....
Hardware : BCM2835
Revision : d03114
Serial : 10000000090946d0
Model : Raspberry Pi 4 Model B Rev 1.4
[raspi4:~:72387] cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 10 (buster)"
NAME="Debian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
[raspi4:~:72388] uname -m
aarch64

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

On 6/25/2021 1:56 PM, Anton Ertl wrote:
> BGB <cr88192@gmail.com> writes:
>> Likely, A64 could be a little better here, but is hindered mostly by a
>> general lack of usable 64-bit builds of Raspbian and similar.
>
> [raspi4:~:72386] cat /proc/cpuinfo
> ...
> Hardware : BCM2835
> Revision : d03114
> Serial : 10000000090946d0
> Model : Raspberry Pi 4 Model B Rev 1.4
> [raspi4:~:72387] cat /etc/os-release
> PRETTY_NAME="Debian GNU/Linux 10 (buster)"
> NAME="Debian GNU/Linux"
> VERSION_ID="10"
> VERSION="10 (buster)"
> VERSION_CODENAME=buster
> ID=debian
> HOME_URL="https://www.debian.org/"
> SUPPORT_URL="https://www.debian.org/support"
> BUG_REPORT_URL="https://bugs.debian.org/"
> [raspi4:~:72388] uname -m
> aarch64
>

So, you are saying to run a A64 Debian build rather than dealing with an
incomplete/broken version of 64-bit Raspbian, or dealing with the
limitations of 32-bit Raspbian?...

> - anton
>

On Friday, June 25, 2021 at 4:55:43 AM UTC-5, Michael S wrote:
> On Friday, June 25, 2021 at 12:49:03 AM UTC+3, BGB wrote:
> > On 6/24/2021 1:44 PM, MitchAlsup wrote:
> > > On Thursday, June 24, 2021 at 12:49:14 PM UTC-5, BGB wrote:
> > >> On 6/24/2021 11:50 AM, MitchAlsup wrote:
> > >>> On Thursday, June 24, 2021 at 8:55:02 AM UTC-5, BGB wrote:
> > >>>> (Got distracted, posting got delayed...)
> > >>>> On 6/22/2021 2:26 PM, MitchAlsup wrote:
> > >>>
> > >>>>> <
> > >>>>> I hope this is for better reasons than MIPS used in R2000 and R3000.....
> > >>>>> <
> > >>>>> R0 is the only register with HW defined use--and that is
> > >>>>> a) gets IP return address when a CALL is performed
> > >>>>> b) is an alias for IP when used as a base register
> > >>>>> c) is an alias for zero when used as an index register
> > >>>>> <
> > >>>>> R31 (SP) has a bit that changes how ENTER and EXIT work
> > >>>>> R30 (FP) has a bit that changes how ENTER and EXIT work.
> > >>> <
> > >>>> R0: May be stomped without warning if one tries to encode an operation
> > >>>> with an immediate, and the immediate form can't otherwise be encoded for
> > >>>> whatever reason.
> > >>> <
> > >>> I got rid of any need to stomp registers other than direct instructions.
> > >>> So, My 66000 does not stomp any registers, it can supply immediates
> > >>> of appropriate sizes.
> > >> The original design was built around the assumption of register stomping
> > >> (for both R0 and R1).
> > >>
> > >> With the ISA as it exists now, there is a lot less of it, but it still
> > >> exists as a possibility. The stomp register was made mostly off-limits
> > >> mostly because a "not off-limits" stomp register was super annoying in
> > >> its predecessors (SH and BJX1).
> > >>
> > >> I moved the stuff that would have originally used R0 and R1 in the SH
> > >> ABI to use R2 and R3 in the BJX2 ABI.
> > >>
> > >>
> > >> R1 ends up being used a lot as a "secondary stomp register" by the
> > >> compiler, typically when generating an instruction sequence for a 3AC op
> > >> will require a temporary register (similar for R16 and R17).
> > >>
> > >> But, since these aren't really allowed as memory base or displacements,
> > >> some built-in ops (such as memory copies) need to use the other scratch
> > >> registers, which then blows the function's status as a "pure leaf" (so
> > >> it creates a stack frame and uses the old register allocator).
> > >>
> > >> At present, the "pure leaf" status also excludes functions containing
> > >> floating point and vector types, but this may change later.
> > >>>>
> > >>>> Say, assuming Jumbo isn't allowed:
> > >>>> ADD R4, -9999, R6
> > >>>> Might be encoded as if it were:
> > >>>> MOV -9999, R0
> > >>>> ADD R4, R0, R6
> > >>> <
> > >>> You are using instructions to build and deliver constants into the instruction stream.
> > >> As noted, "assuming Jumbo isn't allowed".
> > >>
> > >> If Jumbo is allowed, this case can be in-effect encoded as a single
> > >> instruction.
> > >>
> > >>
> > >> Jumbo isn't always allowed though:
> > >> It is still an optional feature as far as the ISA is concerned:
> > >> Lite profile cores are allowed to omit it (1).
> > > <
> > > This is a choice bordering on the poor end of the spectrum of choices.
> > >>
> > >>
> > >> *1: The Lite profile may differ in a few ways:
> > >> Scalar only;
> > >> 16/32 bit ops only;
> > >> Jumbo is optional (*2);
> > > <
> > > Note: Even VVM is mandatory in My 66000--but VVM can be performed on
> > > a 1-wide in-order machine with no extra circuits other than a VVM sequencer.
> > > <
> > >> FPU and MMU are optional;
> > > <
> > > Bad choice:: My 66000 does not even come out of reset with the MMU turned off !!
> > > Even I/O is defined to pass through an I/O MMU.
> > The FPU and MMU are required for the Full profile, but not for the Lite
> > profile.
> >
> > The Lite profile is intended more for use as a microcontroller, and
> > these profiles are not required to be binary compatible.
> >
> >
> > Granted, potentially a MMU could stretch KB of RAM a little further, if
> > one is implementing virtual memory onto an SDcard or similar. Though,
> > even 4K pages are a pretty coarse granularity when the RAM is in KB
> > territory.
> >
> > Though it could almost make sense in this case to try devising some sort
> > of "Use SDcard like non-volatile RAM" mechanism (or externally wire up a
> > QSPI SRAM module or similar).
> >
> >
> > An FPU is kinda expensive, and not really needed in a microcontroller.
> > > <
> > > I would not design an ISA these days, with available gate counts, that does not
> > > have FP built in.
> > > <
> > The FPU exists in the Full profile, just it is a bit of a stretch on the
> > smaller FPGAs.
> >
> > Similarly, the MMU adds a lot of cost for a small scalar core, and one
> > might want to, say, try to keep their core under 10k LUTs so that they
> > can have some space left for IO devices and similar.
> > >> No 128-bit operations;
> > > <
> > > All access to multi-precision stuff is through CARRY in My 66000. CARRY
> > > is not optional, but it is only a couple of sequences on low end processors.
> > > <
> > This mostly covers MOV.X and 128-bit SIMD, which as-implemented require
> > multiple lanes. On a Lite core it needs to be broken up into MOV.Q ops.
> > >> Uses a smaller address space
> > >> 32-bit physical, split into a 30-bit (RAM) and 28-bit region (MMIO).
> > > <
> > > I control this through the <non optional> MMU. The programmer sees
> > > either a 32-bit virtual address space or a 64-bit virtual address space.
> > > Either of which may see a 40-bit-to-64-bit physical address space.
> > Currently, it is 32-bit in Lite, 48 bit in Full.
> >
> > The current physical space is a 30-bit RAM space:
> > 0000_0000 .. 3FFF_FFFF
> > And, 28-bit MMIO space:
> > F000_0000 .. FFFF_FFFF
> >
> > Could support a bigger physical space, but none of the FPGA boards I
> > have, have enough RAM to make this worthwhile.
> >
> > For now, RAM generally goes into the area:
> > 0100_0000 .. 07FF_FFFF
> >
> >
> > On the CMod-S7 I have, it puts its RAM space into:
> > 0100_0000 .. 0101_FFFF
> >
> > In this case, the L2 cache functions as RAM, because there is no
> > external RAM on this board.
> >
> > Another (slightly more expensive) version of the CMod board had a 512K
> > RAM module though, but the board I got didn't have any RAM.
> > >>
> > >> This is mostly to make it viable to use on the XC7S25 and similar (or
> > >> potentially also various ECP5 devices or similar). Granted, in this area
> > >> it would face more competition against RISC-V or similar.
> > >>
> > > I am aware of your implementation limitations.
> > As can be noted though, I am mostly targeting the XC7A100...
> >
> >
> > But, the XC7S25 is more limited than the XC7A100, as are most of the
> > ECP5 chips.
> >
> > The ECP5's can have a decent number of LUTs, but are a little more
> > limited in that it is built around LUT4's.
> >
> > There is also ICE40, but there is little hope of fitting a BJX2 core
> > onto an ICE40. For the most part, people are doing 8/16 designs on ICE40
> > though.
> >
> I have no idea who are "people" you are talking about. Would think that most of them are enthusiasts rather than pros.
>
> Me, being a pro, I very much prefer 32-bit soft cores, supported by standard compilers (in practice it means gcc).
> For convenience of reliable tools I am fully willing to a cost of pretty low MIPS/MHz, which would be typical for
> resource-constrained implementation of such core.
> In particular, I often use Nios2e core that gives ~0.15 MIPS/MHz, fits in ~600 4-input LUTs + 2 Embedded memory banks
> and hits pretty high frequencies. I would guess, that at your XC7A100 it will be close to 200MHz.
> core like that fits with ease within iCE5LP4K and for some less logic-intensive apps can be useful even in iCE5LP2K.
>
> Of course, Nios2 is property of Altera/Intel and (IANAAL) most likely can't be legally used on Lattice devices.
> But it's extremly similar to fixed-width variant of RV32 which is certainly legal to use everywhere.
>
> I didn't check if soft RV32 cores of these class are available, for a little cost or completely free of charge, but personally
> I will be very surprised if they are not available. Because designing such core is ~6 weeks of dedicated work for a above
> average, but not outstanding CA student. Not including validation. I have no feeling about cost of validation of MMU-less
> RV32, because it strongly depends on maturity of available tools, into which I never looked.
>
> I don't even think that ~0.15 MIPS/MHz in ~600 4-input LUTs is the best possible. Trading off a bit of achievable
> frequency, one can do 0.25 MIPS/MHz in 600 LUTs or over 0.5 MIPS/MHz in 750-800 LUTs.
> I know, because I played with these things couple of years ago, under few artificial constraints, in order to make a play more
> interesting. Generally designing CPUs is not my passion, so after 2-3 months of playing I lost interest, but I got to the stage
> where few of my core variants were running real useful software (one of our production utilities, mostly ECDSA validation)
> and measured performances and utilization of FPGA resources, so I consider myself somewhat qualified to make statements
> like above.
> >
> > Though, one can argue though that even on the lower-end, the FPGAs still
> > aren't particularly cost-competitive with a Teensy or Pi Pico or
> > similar... But, can have more powerful IO.

JimBrakefield <jim.brakefield@ieee.org> schrieb:

> Sorted the list of open fpga/soft CPU cores by word size and LUT count.
> To be found at: https://github.com/jimbrake/cpu_soft_cores

That appears to be a very nice overview, but hard to read because
it is PDF with very many columns.

Would it be possibe to put the info into a more spreadsheet or
awk-friendly format like tab-separated values?

BGB <cr88192@gmail.com> writes:
>On 6/25/2021 1:56 PM, Anton Ertl wrote:
>> BGB <cr88192@gmail.com> writes:
>>> Likely, A64 could be a little better here, but is hindered mostly by a
>>> general lack of usable 64-bit builds of Raspbian and similar.
>>
>> [raspi4:~:72386] cat /proc/cpuinfo
>> ...
>> Hardware : BCM2835
>> Revision : d03114
>> Serial : 10000000090946d0
>> Model : Raspberry Pi 4 Model B Rev 1.4
>> [raspi4:~:72387] cat /etc/os-release
>> PRETTY_NAME="Debian GNU/Linux 10 (buster)"
>> NAME="Debian GNU/Linux"
>> VERSION_ID="10"
>> VERSION="10 (buster)"
>> VERSION_CODENAME=buster
>> ID=debian
>> HOME_URL="https://www.debian.org/"
>> SUPPORT_URL="https://www.debian.org/support"
>> BUG_REPORT_URL="https://bugs.debian.org/"
>> [raspi4:~:72388] uname -m
>> aarch64
>>
>
>So, you are saying to run a A64 Debian build rather than dealing with an
>incomplete/broken version of 64-bit Raspbian, or dealing with the
>limitations of 32-bit Raspbian?...

We are running a 64-bit image for the Raspi4, and one user has
programmed the GPIO pins on this machine. I don't know if this is a
64-bit Raspbian or something else, but I guess the difference is
minor. It's not proper (i.e., 32-bit) Raspbian anyway, so the
community benefit of Raspbian is not there.

Anyway, wrt to your sentence above, I don't see any hindrance if you
want to run your simulator on Aarch64.

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

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>We are running a 64-bit image for the Raspi4, and one user has
>programmed the GPIO pins on this machine. I don't know if this is a
>64-bit Raspbian or something else, but I guess the difference is
>minor.

I have now read
<https://linuxhint.com/raspberry-pi-os-vs-armbian-vs-debian-gnu-linux/>
that (32-bit) Raspbian is compiled for a different architecture than
Debian for armhf (one instruction less). Given that Debian arm64 runs
on Raspi3 and Raspi4, there is no such difference necessary for a
64-bit Raspbian.

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

On Saturday, June 26, 2021 at 2:29:01 AM UTC-5, Thomas Koenig wrote:
> JimBrakefield <jim.bra...@ieee.org> schrieb:
> > Sorted the list of open fpga/soft CPU cores by word size and LUT count.
> > To be found at: https://github.com/jimbrake/cpu_soft_cores
> That appears to be a very nice overview, but hard to read because
> it is PDF with very many columns.
>
> Would it be possibe to put the info into a more spreadsheet or
> awk-friendly format like tab-separated values?

Done. Single spreadsheet with multiple sheets.
Usually zoom to the entire width of a 1080x1920 screen.
Column descriptions at the bottom of each sheet.
Would be pleased if people would run some of these designs and report.