On 17/07/2023 3:38 pm, Lorem Ipsum wrote:
> On Sunday, July 16, 2023 at 11:21:09 PM UTC-4, dxforth wrote:
>> On 16/07/2023 8:48 pm, Lorem Ipsum wrote:
>>> On Sunday, July 16, 2023 at 6:45:51 AM UTC-4, dxforth wrote:
>>>> On 15/07/2023 5:34 pm, Lorem Ipsum wrote:
>>>>> On Saturday, July 15, 2023 at 1:24:15 AM UTC-4, dxforth wrote:
>>>>>> On 15/07/2023 2:04 pm, Brian Fox wrote:
>>>>>>> On Friday, July 14, 2023 at 3:27:38 PM UTC-4, Lorem Ipsum wrote:
>>>>>>>
>>>>>>>>> "Fast, Good, Cheap. Pick two"
>>>>>>>> Not sure how that trope applies here.
>>>>>>>
>>>>>>> I was considering stack machine versus register machine
>>>>>>> advantages/tradeoffs as I wrote it.
>>>>>>>
>>>>>>> I am sure there is a better trope. I just don't have one.
>>>>>> In the case of AVR8 there is some sort of trade-off at play. These
>>>>>> devices have quite small flash yet instruction sizes are relatively
>>>>>> large. Were there a better option Atmel (or a competitor) would have
>>>>>> used it.
>>>>>
>>>>> Better in what way? Often decisions are made so the product does not appear "goofy". For example, users are biased to hate instruction words that are not powers of 2. I suppose that's because of the typical mixing of data and instructions. I think some of the PICs have 12 bit instructions and no mixing. I suppose that would be a Harvard architecture. I can't think of any others.
>>>>> ...
>>>>
>>>> The 8085 had few registers, variable-length instructions as short as one
>>>> byte, 16-bit push/pops (also one byte). To my mind the latter would have
>>>> been a better model for the flash sizes typically found in AVR devices.
>>>> What use is a 1 cycle instruction CPU if the program doesn't fit.
>>>
>>> Sorry, I don't follow what you are trying to say.
>> Current 8-bit CPU's are not memory efficient.
>
> And this is relevant to the conversation in what way? I'm just now following the flow of thought. I mentioned that instruction sized vary, but are mostly powers of two and gave an exception. You made a comment that doesn't seem to flow from that. I don't get the connection.
>

It's news to me customers are biased towards instructions being a power (multiple?)
of two. They buy what's available which at the moment is 1 cycle CPU's. Even if
customers are aware it may not be best fit, what are they going to do - design their
own CPU? Manufacturers have customers by the short and curlies.

On Monday, July 17, 2023 at 6:37:45 AM UTC-4, dxforth wrote:
> On 17/07/2023 3:38 pm, Lorem Ipsum wrote:
> > On Sunday, July 16, 2023 at 11:21:09 PM UTC-4, dxforth wrote:
> >> On 16/07/2023 8:48 pm, Lorem Ipsum wrote:
> >>> On Sunday, July 16, 2023 at 6:45:51 AM UTC-4, dxforth wrote:
> >>>> On 15/07/2023 5:34 pm, Lorem Ipsum wrote:
> >>>>> On Saturday, July 15, 2023 at 1:24:15 AM UTC-4, dxforth wrote:
> >>>>>> On 15/07/2023 2:04 pm, Brian Fox wrote:
> >>>>>>> On Friday, July 14, 2023 at 3:27:38 PM UTC-4, Lorem Ipsum wrote:
> >>>>>>>
> >>>>>>>>> "Fast, Good, Cheap. Pick two"
> >>>>>>>> Not sure how that trope applies here.
> >>>>>>>
> >>>>>>> I was considering stack machine versus register machine
> >>>>>>> advantages/tradeoffs as I wrote it.
> >>>>>>>
> >>>>>>> I am sure there is a better trope. I just don't have one.
> >>>>>> In the case of AVR8 there is some sort of trade-off at play. These
> >>>>>> devices have quite small flash yet instruction sizes are relatively
> >>>>>> large. Were there a better option Atmel (or a competitor) would have
> >>>>>> used it.
> >>>>>
> >>>>> Better in what way? Often decisions are made so the product does not appear "goofy". For example, users are biased to hate instruction words that are not powers of 2. I suppose that's because of the typical mixing of data and instructions. I think some of the PICs have 12 bit instructions and no mixing. I suppose that would be a Harvard architecture. I can't think of any others.
> >>>>> ...
> >>>>
> >>>> The 8085 had few registers, variable-length instructions as short as one
> >>>> byte, 16-bit push/pops (also one byte). To my mind the latter would have
> >>>> been a better model for the flash sizes typically found in AVR devices.
> >>>> What use is a 1 cycle instruction CPU if the program doesn't fit.
> >>>
> >>> Sorry, I don't follow what you are trying to say.
> >> Current 8-bit CPU's are not memory efficient.
> >
> > And this is relevant to the conversation in what way? I'm just now following the flow of thought. I mentioned that instruction sized vary, but are mostly powers of two and gave an exception. You made a comment that doesn't seem to flow from that. I don't get the connection.
> >
> It's news to me customers are biased towards instructions being a power (multiple?)
> of two. They buy what's available which at the moment is 1 cycle CPU's. Even if
> customers are aware it may not be best fit, what are they going to do - design their
> own CPU? Manufacturers have customers by the short and curlies.

There are times you make absolutely no sense. Customers have choice. The vast majority of CPUs have instruction sizes of 8, 16, 32, or 64 bits. Some, when addresses are combined with the opcode, will result in 48 bit instructions, but otherwise, the non-binary power sizes are very unusual. The only one I can even think of is the 12 bit instruction PIC.

So, what are you trying to say?

--

Rick C.

-+- Get 1,000 miles of free Supercharging
-+- Tesla referral code - https://ts.la/richard11209

On 18/07/2023 8:47 am, Lorem Ipsum wrote:
> On Monday, July 17, 2023 at 6:37:45 AM UTC-4, dxforth wrote:
>> On 17/07/2023 3:38 pm, Lorem Ipsum wrote:
>>> On Sunday, July 16, 2023 at 11:21:09 PM UTC-4, dxforth wrote:
>>>> On 16/07/2023 8:48 pm, Lorem Ipsum wrote:
>>>>> On Sunday, July 16, 2023 at 6:45:51 AM UTC-4, dxforth wrote:
>>>>>> On 15/07/2023 5:34 pm, Lorem Ipsum wrote:
>>>>>>> On Saturday, July 15, 2023 at 1:24:15 AM UTC-4, dxforth wrote:
>>>>>>>> On 15/07/2023 2:04 pm, Brian Fox wrote:
>>>>>>>>> On Friday, July 14, 2023 at 3:27:38 PM UTC-4, Lorem Ipsum wrote:
>>>>>>>>>
>>>>>>>>>>> "Fast, Good, Cheap. Pick two"
>>>>>>>>>> Not sure how that trope applies here.
>>>>>>>>>
>>>>>>>>> I was considering stack machine versus register machine
>>>>>>>>> advantages/tradeoffs as I wrote it.
>>>>>>>>>
>>>>>>>>> I am sure there is a better trope. I just don't have one.
>>>>>>>> In the case of AVR8 there is some sort of trade-off at play. These
>>>>>>>> devices have quite small flash yet instruction sizes are relatively
>>>>>>>> large. Were there a better option Atmel (or a competitor) would have
>>>>>>>> used it.
>>>>>>>
>>>>>>> Better in what way? Often decisions are made so the product does not appear "goofy". For example, users are biased to hate instruction words that are not powers of 2. I suppose that's because of the typical mixing of data and instructions. I think some of the PICs have 12 bit instructions and no mixing. I suppose that would be a Harvard architecture. I can't think of any others.
>>>>>>> ...
>>>>>>
>>>>>> The 8085 had few registers, variable-length instructions as short as one
>>>>>> byte, 16-bit push/pops (also one byte). To my mind the latter would have
>>>>>> been a better model for the flash sizes typically found in AVR devices.
>>>>>> What use is a 1 cycle instruction CPU if the program doesn't fit.
>>>>>
>>>>> Sorry, I don't follow what you are trying to say.
>>>> Current 8-bit CPU's are not memory efficient.
>>>
>>> And this is relevant to the conversation in what way? I'm just now following the flow of thought. I mentioned that instruction sized vary, but are mostly powers of two and gave an exception. You made a comment that doesn't seem to flow from that. I don't get the connection.
>>>
>> It's news to me customers are biased towards instructions being a power (multiple?)
>> of two. They buy what's available which at the moment is 1 cycle CPU's. Even if
>> customers are aware it may not be best fit, what are they going to do - design their
>> own CPU? Manufacturers have customers by the short and curlies.
>
> There are times you make absolutely no sense. Customers have choice. The vast majority of CPUs have instruction sizes of 8, 16, 32, or 64 bits. Some, when addresses are combined with the opcode, will result in 48 bit instructions, but otherwise, the non-binary power sizes are very unusual. The only one I can even think of is the 12 bit instruction PIC.
>
> So, what are you trying to say?

I've already said it. Current 8-bit CPU's are not memory efficient. Users didn't
decide that.

On Monday, July 17, 2023 at 10:18:39 PM UTC-4, dxforth wrote:
> On 18/07/2023 8:47 am, Lorem Ipsum wrote:
> > On Monday, July 17, 2023 at 6:37:45 AM UTC-4, dxforth wrote:
> >> On 17/07/2023 3:38 pm, Lorem Ipsum wrote:
> >>> On Sunday, July 16, 2023 at 11:21:09 PM UTC-4, dxforth wrote:
> >>>> On 16/07/2023 8:48 pm, Lorem Ipsum wrote:
> >>>>> On Sunday, July 16, 2023 at 6:45:51 AM UTC-4, dxforth wrote:
> >>>>>> On 15/07/2023 5:34 pm, Lorem Ipsum wrote:
> >>>>>>> On Saturday, July 15, 2023 at 1:24:15 AM UTC-4, dxforth wrote:
> >>>>>>>> On 15/07/2023 2:04 pm, Brian Fox wrote:
> >>>>>>>>> On Friday, July 14, 2023 at 3:27:38 PM UTC-4, Lorem Ipsum wrote:
> >>>>>>>>>
> >>>>>>>>>>> "Fast, Good, Cheap. Pick two"
> >>>>>>>>>> Not sure how that trope applies here.
> >>>>>>>>>
> >>>>>>>>> I was considering stack machine versus register machine
> >>>>>>>>> advantages/tradeoffs as I wrote it.
> >>>>>>>>>
> >>>>>>>>> I am sure there is a better trope. I just don't have one.
> >>>>>>>> In the case of AVR8 there is some sort of trade-off at play. These
> >>>>>>>> devices have quite small flash yet instruction sizes are relatively
> >>>>>>>> large. Were there a better option Atmel (or a competitor) would have
> >>>>>>>> used it.
> >>>>>>>
> >>>>>>> Better in what way? Often decisions are made so the product does not appear "goofy". For example, users are biased to hate instruction words that are not powers of 2. I suppose that's because of the typical mixing of data and instructions. I think some of the PICs have 12 bit instructions and no mixing. I suppose that would be a Harvard architecture. I can't think of any others.
> >>>>>>> ...
> >>>>>>
> >>>>>> The 8085 had few registers, variable-length instructions as short as one
> >>>>>> byte, 16-bit push/pops (also one byte). To my mind the latter would have
> >>>>>> been a better model for the flash sizes typically found in AVR devices.
> >>>>>> What use is a 1 cycle instruction CPU if the program doesn't fit.
> >>>>>
> >>>>> Sorry, I don't follow what you are trying to say.
> >>>> Current 8-bit CPU's are not memory efficient.
> >>>
> >>> And this is relevant to the conversation in what way? I'm just now following the flow of thought. I mentioned that instruction sized vary, but are mostly powers of two and gave an exception. You made a comment that doesn't seem to flow from that. I don't get the connection.
> >>>
> >> It's news to me customers are biased towards instructions being a power (multiple?)
> >> of two. They buy what's available which at the moment is 1 cycle CPU's.. Even if
> >> customers are aware it may not be best fit, what are they going to do - design their
> >> own CPU? Manufacturers have customers by the short and curlies.
> >
> > There are times you make absolutely no sense. Customers have choice. The vast majority of CPUs have instruction sizes of 8, 16, 32, or 64 bits. Some, when addresses are combined with the opcode, will result in 48 bit instructions, but otherwise, the non-binary power sizes are very unusual. The only one I can even think of is the 12 bit instruction PIC.
> >
> > So, what are you trying to say?
> I've already said it. Current 8-bit CPU's are not memory efficient. Users didn't
> decide that.

Ok, enjoy.

--

Rick C.

-++ Get 1,000 miles of free Supercharging
-++ Tesla referral code - https://ts.la/richard11209

In article <a262ff14-cd28-4713-875e-73c604b9faa5n@googlegroups.com>,
Lorem Ipsum <gnuarm.deletethisbit@gmail.com> wrote:
>There are times you make absolutely no sense. Customers have choice.
>The vast majority of CPUs have instruction sizes of 8, 16, 32, or 64
>bits. Some, when addresses are combined with the opcode, will result in
>48 bit instructions, but otherwise, the non-binary power sizes are very
>unusual. The only one I can even think of is the 12 bit instruction
>PIC.

This makes sense because of memories. Memories in multiples of bytes
(octets) are practical and have gained the upper hand not only in
hardware but also in software.
It is unimaginable that the billion euro's investment needed for
10 bit memories are duplicated.
This more or less dictates a decision that busses are a multiple of
8 and consequences for the CPU architectures.

> Rick C.
Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

none albert schrieb am Dienstag, 18. Juli 2023 um 07:27:34 UTC+2:
> In article <a262ff14-cd28-4713...@googlegroups.com>,
> Lorem Ipsum <gnuarm.del...@gmail.com> wrote:
> >There are times you make absolutely no sense. Customers have choice.
> >The vast majority of CPUs have instruction sizes of 8, 16, 32, or 64
> >bits. Some, when addresses are combined with the opcode, will result in
> >48 bit instructions, but otherwise, the non-binary power sizes are very
> >unusual. The only one I can even think of is the 12 bit instruction
> >PIC.
> This makes sense because of memories. Memories in multiples of bytes
> (octets) are practical and have gained the upper hand not only in
> hardware but also in software.
> It is unimaginable that the billion euro's investment needed for
> 10 bit memories are duplicated.
> This more or less dictates a decision that busses are a multiple of
> 8 and consequences for the CPU architectures.

Adding: most CPUS in the world are NOT used for computing but for device
controls. F.ex. most analog-to-digital or digital-to-analog converters
have bandwiths that are not powers of two.

On Tuesday, July 18, 2023 at 1:27:34 AM UTC-4, none albert wrote:
> In article <a262ff14-cd28-4713...@googlegroups.com>,
> Lorem Ipsum <gnuarm.del...@gmail.com> wrote:
> >There are times you make absolutely no sense. Customers have choice.
> >The vast majority of CPUs have instruction sizes of 8, 16, 32, or 64
> >bits. Some, when addresses are combined with the opcode, will result in
> >48 bit instructions, but otherwise, the non-binary power sizes are very
> >unusual. The only one I can even think of is the 12 bit instruction
> >PIC.
> This makes sense because of memories. Memories in multiples of bytes
> (octets) are practical and have gained the upper hand not only in
> hardware but also in software.

You seem to be conflating data memory and program memory. There is no reason for the two to be common, really. Most program storage in smaller MCUs is Flash, while the data is mostly used in RAM. There is no reason to limit flash program storage to bytes. There is no "upper hand".

> It is unimaginable that the billion euro's investment needed for
> 10 bit memories are duplicated.

That makes no sense. Memory is no different from logic. If you need 10 bit memory, enter a 10 for bit width in the tool that designs the memory.

> This more or less dictates a decision that busses are a multiple of
> 8 and consequences for the CPU architectures.

Sorry, I don't see your logic.

--

Rick C.

+-- Get 1,000 miles of free Supercharging
+-- Tesla referral code - https://ts.la/richard11209

On 18/07/2023 3:27 pm, albert wrote:
> In article <a262ff14-cd28-4713-875e-73c604b9faa5n@googlegroups.com>,
> Lorem Ipsum <gnuarm.deletethisbit@gmail.com> wrote:
>> There are times you make absolutely no sense. Customers have choice.
>> The vast majority of CPUs have instruction sizes of 8, 16, 32, or 64
>> bits. Some, when addresses are combined with the opcode, will result in
>> 48 bit instructions, but otherwise, the non-binary power sizes are very
>> unusual. The only one I can even think of is the 12 bit instruction
>> PIC.
>
> This makes sense because of memories. Memories in multiples of bytes
> (octets) are practical and have gained the upper hand not only in
> hardware but also in software.
> It is unimaginable that the billion euro's investment needed for
> 10 bit memories are duplicated.
> This more or less dictates a decision that busses are a multiple of
> 8 and consequences for the CPU architectures.

Only issue would be data stored in program memory. FlashForth handles
it through de-blocking and address munging. To a user, data in program
memory appears byte-addressed and word-aligned when in reality it's a
different beast altogether.

On Wednesday, July 19, 2023 at 12:27:01 AM UTC-4, dxforth wrote:
> On 18/07/2023 3:27 pm, albert wrote:
> > In article <a262ff14-cd28-4713...@googlegroups.com>,
> > Lorem Ipsum <gnuarm.del...@gmail.com> wrote:
> >> There are times you make absolutely no sense. Customers have choice.
> >> The vast majority of CPUs have instruction sizes of 8, 16, 32, or 64
> >> bits. Some, when addresses are combined with the opcode, will result in
> >> 48 bit instructions, but otherwise, the non-binary power sizes are very
> >> unusual. The only one I can even think of is the 12 bit instruction
> >> PIC.
> >
> > This makes sense because of memories. Memories in multiples of bytes
> > (octets) are practical and have gained the upper hand not only in
> > hardware but also in software.
> > It is unimaginable that the billion euro's investment needed for
> > 10 bit memories are duplicated.
> > This more or less dictates a decision that busses are a multiple of
> > 8 and consequences for the CPU architectures.
> Only issue would be data stored in program memory. FlashForth handles
> it through de-blocking and address munging. To a user, data in program
> memory appears byte-addressed and word-aligned when in reality it's a
> different beast altogether.

No rocket science there. Harvard architectures have been used in many devices, some with mismatched data sizes.

I design my own processors. I have typically used a 4 or 5 bit instruction word, which never really matches the data paths. In fact, the data paths are not coded in any meaningful way other than a constant at compile time. The instruction set is data path agnostic. Read only type memory (even if it's only in use and actually in RAM) can be added to data memory as well as to the instruction space.

I don't see any constraints, other than that users like to see lots of symmetry. Meanwhile, the very symmetric 68000 and Power PC architectures have faded away to be replaced by the Intel lines. But maybe I shouldn't drag large CPUs into what is essentially a small CPU discussion. I'm not so familiar with the various small CPU ISAs. I know some are positively bizarre, like the 1802. I can't recall the heritage of that CPU, but it has to have some history to be so odd.

--

Rick C.

+-+ Get 1,000 miles of free Supercharging
+-+ Tesla referral code - https://ts.la/richard11209

In article <f3836786-0a36-4d32-a8c7-481f247ea263n@googlegroups.com>,
Lorem Ipsum <gnuarm.deletethisbit@gmail.com> wrote:
<SNIP>
>No rocket science there. Harvard architectures have been used in many
>devices, some with mismatched data sizes.

Harvard architectures with the possibility to write program memory
are in fact botched Newman architectures.

>I don't see any constraints, other than that users like to see lots of
>symmetry. Meanwhile, the very symmetric 68000 and Power PC
>architectures have faded away to be replaced by the Intel lines. But

The newest development is that the CISCy Intel lines fades
away quickly to be replaced by the all too symmetric risc-V.
Users (like me) like that.

> Rick C.

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

On Wednesday, July 19, 2023 at 6:33:16 AM UTC-4, none albert wrote:
> In article <f3836786-0a36-4d32...@googlegroups.com>,
> Lorem Ipsum <gnuarm.del...@gmail.com> wrote:
> <SNIP>
> >No rocket science there. Harvard architectures have been used in many
> >devices, some with mismatched data sizes.
> Harvard architectures with the possibility to write program memory
> are in fact botched Newman architectures.

If you say so.

> >I don't see any constraints, other than that users like to see lots of
> >symmetry. Meanwhile, the very symmetric 68000 and Power PC
> >architectures have faded away to be replaced by the Intel lines. But
> The newest development is that the CISCy Intel lines fades
> away quickly to be replaced by the all too symmetric risc-V.
> Users (like me) like that.

Hmmm... I guess you are relating your dreams. Risc-V seems to be catching on in the MCU world where royalties are anathema, well, at least for the Chinese market. I've not seen any indication of Intel losing market share to the Risc-V in their pricier product lines.

I realize that you like to pull people's legs and often live in a fantasy world. Why do you want to pretend like Risc-V is a significant CPU competing with the Intel lines?

--

Rick C.

++- Get 1,000 miles of free Supercharging
++- Tesla referral code - https://ts.la/richard11209

> I realize that you like to pull people's legs and often live in a fantasy world. Why do you want to pretend like Risc-V is a significant CPU competing with the Intel lines?

Haha, wait for it! RISC-V is advancing quickly. Have you seen the announcement that the Debian team plans official riscv64 architecture support in the upcoming version 13 "Trixie"?

On Wednesday, July 19, 2023 at 3:56:26 PM UTC-4, Matthias Koch wrote:
> > I realize that you like to pull people's legs and often live in a fantasy world. Why do you want to pretend like Risc-V is a significant CPU competing with the Intel lines?
> Haha, wait for it! RISC-V is advancing quickly. Have you seen the announcement that the Debian team plans official riscv64 architecture support in the upcoming version 13 "Trixie"?

Linux already runs on the rPi and many other small processors. Doesn't mean they are competing with Intel in laptops and desktops in any meaningful way.

I have one of the original rPis. It sucks as a desktop machine, even running just one tab in a browser. Maybe it would be a bit better with an rPi4, but it's not competition for mainstream processors.

Are you seriously going to run compiles or FPGA simulations on a Risc-V instead of an Intel or AMD processor?

What is different about the Risc-V compared to the 68000 family or the Power-PC family? Why would it compete when the others did not? Didn't the Power-PC have the full backing of Sun and IBM, yet it still could not keep up? Even Apple switched to Intel processors.

I don't know how Risc-V will do in the mobile market. From what I've read, the reason it is getting traction is simply because there are no royalties to pay. So it appeals to the Chinese market. Have they ever produced anything that was significant in the mainstream markets?

--

Rick C.

+++ Get 1,000 miles of free Supercharging
+++ Tesla referral code - https://ts.la/richard11209

Matthias Koch <m.cook@gmx.net> writes:
>Have you seen the announcement that the Debian team plans official riscv64 architecture support in the upcoming version 13 "Trixie"?

Ok, lack of support by Debian explains why the Visionfive Starfive V1
that we have had for more than a year had a Fedora image to work with.

Anyway, RISC-V still has quite a bit of catching up ahead of it, but
it has a lot of mindshare, which helps a lot. I expect, though that
it will first eat ARM's lunch before eating Intel's and AMD's dinner,
if that ever happens.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2023: https://euro.theforth.net/2023

Lorem Ipsum <gnuarm.deletethisbit@gmail.com> writes:
>I have one of the original rPis. It sucks as a desktop machine, even runni=
>ng just one tab in a browser. Maybe it would be a bit better with an rPi4,=
> but it's not competition for mainstream processors. =20

It's a lot better with the rPi4. Concerning competetiveness with
Intel's low-end cores:

sieve bubble matrix fib fft release; CPU
0.108 0.135 0.058 0.104 0.039 20230114; Celeron N4500 (Tremont) 2800MHz
0.236 0.276 0.124 0.260 0.119 20230629; BCM2835 (1500MHz A73, Raspberry Pi 4)
0.519 0.555 0.483 0.797 0.729 20220226; 1GHz U74 (JH7100, Visionfive V1)

>What is different about the Risc-V compared to the 68000 family or the Powe=
>r-PC family? Why would it compete when the others did not? Didn't the Pow=
>er-PC have the full backing of Sun and IBM, yet it still could not keep up?=

PowerPC had and still has backing by IBM, but not Sun. It seems that
in the early 2000s the goals of the three components of the AIM
consortium diverged. IBM wanted high-performance CPUs aimed at
supercomputers and video game consoles, Motorola wanted (and produced)
embedded CPUs, and Apple wanted low-power-consumption CPUs for cheap.
Apparently Apple did not want to pay enough for Motorola or IBM to
invest enough to develop CPUs competetive in the metrics relevant for
Apple with what Intel was producing for the PC market.

> Even Apple switched to Intel processors.=20

Maybe it's news to you, but Apple switched from Intel to ARM ("Apple
Silicon") several years ago.

>I don't know how Risc-V will do in the mobile market. From what I've read,=
> the reason it is getting traction is simply because there are no royalties=
> to pay.

The reason RISC-V is gaining traction is because it has academia
behind it. Commercial architectures have been shackled by
rights-holders whims, which makes it problematic to use commercial
architectures in courses or research projects. So the people at
Berkeley started RISC-V in order to get rid of the shackles. And many
in academia choose RISC-V unless there are good reasons to choose
something else; e.g., I am currently writing a paper where the
examples use RISC-V. So in 10 years the market will have lots of
people who know RISC-V.

>So it appeals to the Chinese market.

Not having to pay royalties (ARM tax) for the architecture appeals to
all capitalists, not just the Chinese. One example is WD, who AFAIK
are switching from ARM to RISC-V for their hard disk and SSD
controllers.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2023: https://euro.theforth.net/2023

In article <f7a2be1f-9d98-46da-8762-9b4182347045n@googlegroups.com>,
Lorem Ipsum <gnuarm.deletethisbit@gmail.com> wrote:
<SNI
>I don't know how Risc-V will do in the mobile market. From what I've
>read, the reason it is getting traction is simply because there are no
>royalties to pay. So it appeals to the Chinese market.

My Forth (ciforth) runs on the RISC-V, under linux and I have tested the
programs to control a midi keyboard. (My classic example of a
sophisticated program).
It is hard to see that the lithography machines China develops are
going to be used to produce Intel or even ARM compatible machines.

>Have they ever
>produced anything that was significant in the mainstream markets?
Dont be ridiculous. All but the most technically advanced stuff
is produced in China.
On the more high tech side solar cells and rare earth magnets come to mind.
I have here a 2 XEON total 56 cores 25 Gbyte RAM HP workstation.
All but a few parts are produced in China, Korea and Taiwan.

The more visionary capitalist (Gates, Musk) realize that we are near
a point of infinite production capacity. Something has to give way.
We have a choice of total destruction of the original idea of communism.

> Rick C.

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

In article <u99f56$29sk4$1@dont-email.me>,
Matthias Koch <m.cook@gmx.net> wrote:
>
>> I realize that you like to pull people's legs and often live in a
>fantasy world. Why do you want to pretend like Risc-V is a significant
>CPU competing with the Intel lines?
>
>Haha, wait for it! RISC-V is advancing quickly. Have you seen the
>announcement that the Debian team plans official riscv64 architecture
>support in the upcoming version 13 "Trixie"?

Linux's in the armbian sphere are already available for a long time.
My DshanNezha system has a D1H processor. This System On A CHip has
a 1000 + page exhaustive documentation which allow me to control
gpio lines ("blinking leds") and a 30 Khz serial line (midi)
with ease. Using a 64 bit port of ciforth for RISCV .
The io library had to be adapted from ARM pi's , but the
Forth relies only on system calls, and failed no tests.

The family of 64 bits ciforths has now a new member RISCV
https://home.hccnet.nl/a.w.m.van.der.horst/lina.html

Boards are available. I ordered from https://www.analoglamb.com/
a reliable supplier. (Warning this board is under Linux boards, not
RISCV). If you want to experiment, pay 4 euro's more for the
docking board.
You don't want to connect to .5 mm gold fingers.
The total cost is then 30 euro's

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -