Re: [9fans] Plan 9 C compiler for Xtensa CPUs

Re: [9fans] Plan 9 C compiler for Xtensa CPUs

[David Boddie]

On Sat, 10 Aug 2019 16:18:16 +0000, Charles Forsyth wrote:

> I haven't had a lot of spare time, but I did the assembler and am about 
> 3/4
> through the loader.
> For the most part it's a straightforward RISC.
> Might do the disassembler next to help debug the rest, and finally the
> compiler.

Did you get any further with this? I'm interested in attempting a port
of Inferno to an ESP32 board I've just picked up.
Learning the instruction set is going to be interesting.

David

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T89e396031646ba20-M18104fe21d2fb13232ef76a6
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Plan 9 C compiler for Xtensa CPUs

[Cyber Fonic]

[-- Attachment #1: Type: text/plain, Size: 6450 bytes --]

For IoT deployments, I suppose that one processor core on the ESP32 could
run the WiFi / networking stack and the other act as a CPU-like server and
thus run a small number of servers to expose the interface(s) in a 9P
mountable fashion to more powerful nodes.  A RT-ish kernel might suffice in
most practical use cases - it is IoT after all.  In my vision for Plan9 IoT
I never considered running file-server or terminal server on ESP-32
hardware. There are more capable nodes which would be better suited for
those purposes.  Of course, these observations presume that the 9p protocol
provides sufficient security against any ESP-32 node going rogue for
whatever reason.

It has been said :  "The 'S' in IoT stands for security".  If Plan9 can
address that deficiency of the current state of the art for IoT devices,
then it would be a worthwhile exercise.

On Mon, 19 Aug 2019 at 00:12, Charles Forsyth <charles.forsyth@gmail.com>
wrote:

> There is another existing variant of ESP32 with flash and RAM, and that
> one would provide the external memory MMU.
> It seems there could be a range from a small RT-ish kernel, with and
> without a user mode, on little ESP32, to a Plan 9 kernel with a few
> specialised processes on the bigger one.
> An Inferno-like system might also straddle the boundaries.
>
> On Sat, Aug 10, 2019 at 5:18 PM Charles Forsyth <charles.forsyth@gmail.com>
> wrote:
>
>> At a glance it looked as though the MMUs for the on-chip stuff were more
>> suitable for Unix Seventh Edition (no later) than "full" Plan 9.
>> The MMU for the external memory looked fine, but as I said, the device
>> I've got, and several other boards based on WROOM seem not
>> to bother with external memory. I didn't look widely, though.
>>
>> The processor is adequate, I think, but double == float (there's only
>> single precision).
>>
>> The existing systems use one processor for applications, and the other
>> mainly for communications.
>>
>> I haven't had a lot of spare time, but I did the assembler and am about
>> 3/4 through the loader.
>> For the most part it's a straightforward RISC.
>> Might do the disassembler next to help debug the rest, and finally the
>> compiler.
>>
>> On Sat, Aug 10, 2019 at 10:11 AM Cyber Fonic <cyberfonic@gmail.com>
>> wrote:
>>
>>> The emergent problem with IoT is the lack of security.  From my
>>> understanding of Plan9's architecture. 9p protocol and the "root-less"
>>> security model suggests to me that a Plan9 swarm of IoT devices could be
>>> the "killer app" where Plan9 emerges on the strength of the vision of
>>> decades ago.  Looking at other RT OSes the security models are often bolted
>>> on.  Plan9 worked well on IBM PC era hardware. An ESP-32 has more resources
>>> and better networking than the early PCs.  From my tinkering and reverse
>>> engineering of IoT devices, almost all use 8266 based WiFi and often in
>>> conjunction with a uController. An ESP-32 is dual processor and with
>>> sufficient I/O for most simple tasks.  With IoT, in general, you don't need
>>> a lot of I/O, you simply throw more CPUs into the mix.
>>>
>>> On Sat, 10 Aug 2019 at 08:55, Skip Tavakkolian <
>>> skip.tavakkolian@gmail.com> wrote:
>>>
>>>> I'm not sure if the effort would be worth it; but if you add support
>>>> for esp32, I think it would be better for the os to be something like the
>>>> one you had in kencc for AVR (*) or possibly Russ' libtask, rather than
>>>> Plan 9. Staying with FreeRTOS would need removal of GCC specific things
>>>> from OS and dealing with lots of drivers in C++.
>>>>
>>>> The Cortex-M based mpus (e.g. Teensy 4 with Cortex M7 @ 600MHz) seem
>>>> more appropriate for an "embedded" Plan 9.
>>>>
>>>> (*) for those who have not seen it, it is here:
>>>> % ls -l /n/sources/contrib/forsyth/avr*
>>>> --rw-rw-r-- M 518 bootes sys 251227 Sep  4  2011
>>>> /n/sources/contrib/forsyth/avr.9gz
>>>>
>>>> On Fri, Aug 9, 2019 at 2:36 PM Charles Forsyth <
>>>> charles.forsyth@gmail.com> wrote:
>>>>
>>>>> Since the resources are small if not tiny, a little systems analysis
>>>>> and design is probably needed, but it looks like a bit of fun, until the
>>>>> inevitable moment of "why am I here?".
>>>>>
>>>>> On Fri, Aug 9, 2019 at 4:50 PM Charles Forsyth <
>>>>> charles.forsyth@gmail.com> wrote:
>>>>>
>>>>>> The device I've got is ESP32-WROOM-32. None of the boards I've seen
>>>>>> that use it bother with external memory,
>>>>>> so memory is limited, especially the way it's partitioned.
>>>>>>
>>>>>> On Fri, Aug 9, 2019 at 3:50 PM Charles Forsyth <
>>>>>> charles.forsyth@gmail.com> wrote:
>>>>>>
>>>>>>> The ESP32 has got several MMUs. The characteristics are different
>>>>>>> depending on the part that a given MMU accesses (flash, ROM, SRAM, external
>>>>>>> memory).
>>>>>>> Some things are accessed using Memory Protection Units instead,
>>>>>>> which control access by Process ID, but don't do mapping. Others including
>>>>>>> some of the SRAMs are accessed through
>>>>>>> an MMU that can do virtual to physical mapping. The MMUs for
>>>>>>> internal SRAM0 and 2 choose protection for a given physical page as none,
>>>>>>> one or all of PIDs 2 to 7, with the virtual address that
>>>>>>> maps to it. PIDs 0 and 1 can access everything. PID 0 can execute
>>>>>>> privileged instructions.
>>>>>>> A large chunk of SRAM (SRAM 1) has only Memory Protection and no
>>>>>>> translation. The external memory MMU is the most general (most
>>>>>>> conventional).
>>>>>>>
>>>>>>> On Fri, Aug 9, 2019 at 3:19 PM Bakul Shah <bakul@bitblocks.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> esp32 doesn’t have an mmu, right?
>>>>>>>>
>>>>>>>> On Jul 26, 2019, at 03:30, Charles Forsyth <
>>>>>>>> charles.forsyth@gmail.com> wrote:
>>>>>>>>
>>>>>>>> I was thinking of doing that since I've got an ESP-32 for some
>>>>>>>> reason
>>>>>>>>
>>>>>>>> On Fri, Jul 26, 2019 at 7:38 AM Cyber Fonic <cyberfonic@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> I was reading the post Why Didn't Plan 9 Succeed
>>>>>>>>> <https://news.ycombinator.com/item?id=20527650> on Hacker News.
>>>>>>>>>
>>>>>>>>> Made me think that Plan 9 for IoT system of systems could be
>>>>>>>>> viable.
>>>>>>>>>
>>>>>>>>> To that end, ESP-32 modules look capable enough to run Plan 9, but
>>>>>>>>> is there a Plan 9 C compiler for Xtensa ISA CPUs?
>>>>>>>>>
>>>>>>>>>

[-- Attachment #2: Type: text/html, Size: 9191 bytes --]

Re: [9fans] Plan 9 C compiler for Xtensa CPUs

[Richard Miller]

Charles Forsyth <charles.forsyth@gmail.com:
> I haven't had a lot of spare time, but I did the assembler and am about
> 3/4 through the loader.
> For the most part it's a straightforward RISC.
> Might do the disassembler next to help debug the rest, and finally the
> compiler.

Nowadays I do the disassembler first.  Advantages: (a) useful tool for
debugging the assembler and loader; (b) disassembling binaries produced
by some other toolchain provides a useful check for my understanding of
the instruction encoding.

Re: [9fans] Plan 9 C compiler for Xtensa CPUs

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 5344 bytes --]

There is another existing variant of ESP32 with flash and RAM, and that one
would provide the external memory MMU.
It seems there could be a range from a small RT-ish kernel, with and
without a user mode, on little ESP32, to a Plan 9 kernel with a few
specialised processes on the bigger one.
An Inferno-like system might also straddle the boundaries.

On Sat, Aug 10, 2019 at 5:18 PM Charles Forsyth <charles.forsyth@gmail.com>
wrote:

> At a glance it looked as though the MMUs for the on-chip stuff were more
> suitable for Unix Seventh Edition (no later) than "full" Plan 9.
> The MMU for the external memory looked fine, but as I said, the device
> I've got, and several other boards based on WROOM seem not
> to bother with external memory. I didn't look widely, though.
>
> The processor is adequate, I think, but double == float (there's only
> single precision).
>
> The existing systems use one processor for applications, and the other
> mainly for communications.
>
> I haven't had a lot of spare time, but I did the assembler and am about
> 3/4 through the loader.
> For the most part it's a straightforward RISC.
> Might do the disassembler next to help debug the rest, and finally the
> compiler.
>
> On Sat, Aug 10, 2019 at 10:11 AM Cyber Fonic <cyberfonic@gmail.com> wrote:
>
>> The emergent problem with IoT is the lack of security.  From my
>> understanding of Plan9's architecture. 9p protocol and the "root-less"
>> security model suggests to me that a Plan9 swarm of IoT devices could be
>> the "killer app" where Plan9 emerges on the strength of the vision of
>> decades ago.  Looking at other RT OSes the security models are often bolted
>> on.  Plan9 worked well on IBM PC era hardware. An ESP-32 has more resources
>> and better networking than the early PCs.  From my tinkering and reverse
>> engineering of IoT devices, almost all use 8266 based WiFi and often in
>> conjunction with a uController. An ESP-32 is dual processor and with
>> sufficient I/O for most simple tasks.  With IoT, in general, you don't need
>> a lot of I/O, you simply throw more CPUs into the mix.
>>
>> On Sat, 10 Aug 2019 at 08:55, Skip Tavakkolian <
>> skip.tavakkolian@gmail.com> wrote:
>>
>>> I'm not sure if the effort would be worth it; but if you add support for
>>> esp32, I think it would be better for the os to be something like the one
>>> you had in kencc for AVR (*) or possibly Russ' libtask, rather than Plan 9.
>>> Staying with FreeRTOS would need removal of GCC specific things from OS and
>>> dealing with lots of drivers in C++.
>>>
>>> The Cortex-M based mpus (e.g. Teensy 4 with Cortex M7 @ 600MHz) seem
>>> more appropriate for an "embedded" Plan 9.
>>>
>>> (*) for those who have not seen it, it is here:
>>> % ls -l /n/sources/contrib/forsyth/avr*
>>> --rw-rw-r-- M 518 bootes sys 251227 Sep  4  2011
>>> /n/sources/contrib/forsyth/avr.9gz
>>>
>>> On Fri, Aug 9, 2019 at 2:36 PM Charles Forsyth <
>>> charles.forsyth@gmail.com> wrote:
>>>
>>>> Since the resources are small if not tiny, a little systems analysis
>>>> and design is probably needed, but it looks like a bit of fun, until the
>>>> inevitable moment of "why am I here?".
>>>>
>>>> On Fri, Aug 9, 2019 at 4:50 PM Charles Forsyth <
>>>> charles.forsyth@gmail.com> wrote:
>>>>
>>>>> The device I've got is ESP32-WROOM-32. None of the boards I've seen
>>>>> that use it bother with external memory,
>>>>> so memory is limited, especially the way it's partitioned.
>>>>>
>>>>> On Fri, Aug 9, 2019 at 3:50 PM Charles Forsyth <
>>>>> charles.forsyth@gmail.com> wrote:
>>>>>
>>>>>> The ESP32 has got several MMUs. The characteristics are different
>>>>>> depending on the part that a given MMU accesses (flash, ROM, SRAM, external
>>>>>> memory).
>>>>>> Some things are accessed using Memory Protection Units instead, which
>>>>>> control access by Process ID, but don't do mapping. Others including some
>>>>>> of the SRAMs are accessed through
>>>>>> an MMU that can do virtual to physical mapping. The MMUs for internal
>>>>>> SRAM0 and 2 choose protection for a given physical page as none, one or all
>>>>>> of PIDs 2 to 7, with the virtual address that
>>>>>> maps to it. PIDs 0 and 1 can access everything. PID 0 can execute
>>>>>> privileged instructions.
>>>>>> A large chunk of SRAM (SRAM 1) has only Memory Protection and no
>>>>>> translation. The external memory MMU is the most general (most
>>>>>> conventional).
>>>>>>
>>>>>> On Fri, Aug 9, 2019 at 3:19 PM Bakul Shah <bakul@bitblocks.com>
>>>>>> wrote:
>>>>>>
>>>>>>> esp32 doesn’t have an mmu, right?
>>>>>>>
>>>>>>> On Jul 26, 2019, at 03:30, Charles Forsyth <
>>>>>>> charles.forsyth@gmail.com> wrote:
>>>>>>>
>>>>>>> I was thinking of doing that since I've got an ESP-32 for some reason
>>>>>>>
>>>>>>> On Fri, Jul 26, 2019 at 7:38 AM Cyber Fonic <cyberfonic@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I was reading the post Why Didn't Plan 9 Succeed
>>>>>>>> <https://news.ycombinator.com/item?id=20527650> on Hacker News.
>>>>>>>>
>>>>>>>> Made me think that Plan 9 for IoT system of systems could be viable.
>>>>>>>>
>>>>>>>> To that end, ESP-32 modules look capable enough to run Plan 9, but
>>>>>>>> is there a Plan 9 C compiler for Xtensa ISA CPUs?
>>>>>>>>
>>>>>>>>

[-- Attachment #2: Type: text/html, Size: 7874 bytes --]

Re: [9fans] Plan 9 C compiler for Xtensa CPUs

[Lyndon Nerenberg]

Charles Forsyth writes:

> At a glance it looked as though the MMUs for the on-chip stuff were more
> suitable for Unix Seventh Edition (no later) than "full" Plan 9.

Wouldn't Inferno be a better fit for these sort of devices?

In my experience these things are used primarily as I/O devices,
with most of the CPU cycles going towards reducing/normalizing/marshalling
the data in and out.  Nothing I've ever built out of an ESP*,
Feather, Teensy, etc., would benefit from a full-on Plan9 kernel.

But having a fully-integrated 9P+auth stack would make these
microcontrollers a dream to integrate into a Plan9 environment.

--lyndon

Re: [9fans] Plan 9 C compiler for Xtensa CPUs

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 4769 bytes --]

At a glance it looked as though the MMUs for the on-chip stuff were more
suitable for Unix Seventh Edition (no later) than "full" Plan 9.
The MMU for the external memory looked fine, but as I said, the device I've
got, and several other boards based on WROOM seem not
to bother with external memory. I didn't look widely, though.

The processor is adequate, I think, but double == float (there's only
single precision).

The existing systems use one processor for applications, and the other
mainly for communications.

I haven't had a lot of spare time, but I did the assembler and am about 3/4
through the loader.
For the most part it's a straightforward RISC.
Might do the disassembler next to help debug the rest, and finally the
compiler.

On Sat, Aug 10, 2019 at 10:11 AM Cyber Fonic <cyberfonic@gmail.com> wrote:

> The emergent problem with IoT is the lack of security.  From my
> understanding of Plan9's architecture. 9p protocol and the "root-less"
> security model suggests to me that a Plan9 swarm of IoT devices could be
> the "killer app" where Plan9 emerges on the strength of the vision of
> decades ago.  Looking at other RT OSes the security models are often bolted
> on.  Plan9 worked well on IBM PC era hardware. An ESP-32 has more resources
> and better networking than the early PCs.  From my tinkering and reverse
> engineering of IoT devices, almost all use 8266 based WiFi and often in
> conjunction with a uController. An ESP-32 is dual processor and with
> sufficient I/O for most simple tasks.  With IoT, in general, you don't need
> a lot of I/O, you simply throw more CPUs into the mix.
>
> On Sat, 10 Aug 2019 at 08:55, Skip Tavakkolian <skip.tavakkolian@gmail.com>
> wrote:
>
>> I'm not sure if the effort would be worth it; but if you add support for
>> esp32, I think it would be better for the os to be something like the one
>> you had in kencc for AVR (*) or possibly Russ' libtask, rather than Plan 9.
>> Staying with FreeRTOS would need removal of GCC specific things from OS and
>> dealing with lots of drivers in C++.
>>
>> The Cortex-M based mpus (e.g. Teensy 4 with Cortex M7 @ 600MHz) seem more
>> appropriate for an "embedded" Plan 9.
>>
>> (*) for those who have not seen it, it is here:
>> % ls -l /n/sources/contrib/forsyth/avr*
>> --rw-rw-r-- M 518 bootes sys 251227 Sep  4  2011
>> /n/sources/contrib/forsyth/avr.9gz
>>
>> On Fri, Aug 9, 2019 at 2:36 PM Charles Forsyth <charles.forsyth@gmail.com>
>> wrote:
>>
>>> Since the resources are small if not tiny, a little systems analysis and
>>> design is probably needed, but it looks like a bit of fun, until the
>>> inevitable moment of "why am I here?".
>>>
>>> On Fri, Aug 9, 2019 at 4:50 PM Charles Forsyth <
>>> charles.forsyth@gmail.com> wrote:
>>>
>>>> The device I've got is ESP32-WROOM-32. None of the boards I've seen
>>>> that use it bother with external memory,
>>>> so memory is limited, especially the way it's partitioned.
>>>>
>>>> On Fri, Aug 9, 2019 at 3:50 PM Charles Forsyth <
>>>> charles.forsyth@gmail.com> wrote:
>>>>
>>>>> The ESP32 has got several MMUs. The characteristics are different
>>>>> depending on the part that a given MMU accesses (flash, ROM, SRAM, external
>>>>> memory).
>>>>> Some things are accessed using Memory Protection Units instead, which
>>>>> control access by Process ID, but don't do mapping. Others including some
>>>>> of the SRAMs are accessed through
>>>>> an MMU that can do virtual to physical mapping. The MMUs for internal
>>>>> SRAM0 and 2 choose protection for a given physical page as none, one or all
>>>>> of PIDs 2 to 7, with the virtual address that
>>>>> maps to it. PIDs 0 and 1 can access everything. PID 0 can execute
>>>>> privileged instructions.
>>>>> A large chunk of SRAM (SRAM 1) has only Memory Protection and no
>>>>> translation. The external memory MMU is the most general (most
>>>>> conventional).
>>>>>
>>>>> On Fri, Aug 9, 2019 at 3:19 PM Bakul Shah <bakul@bitblocks.com> wrote:
>>>>>
>>>>>> esp32 doesn’t have an mmu, right?
>>>>>>
>>>>>> On Jul 26, 2019, at 03:30, Charles Forsyth <charles.forsyth@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> I was thinking of doing that since I've got an ESP-32 for some reason
>>>>>>
>>>>>> On Fri, Jul 26, 2019 at 7:38 AM Cyber Fonic <cyberfonic@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I was reading the post Why Didn't Plan 9 Succeed
>>>>>>> <https://news.ycombinator.com/item?id=20527650> on Hacker News.
>>>>>>>
>>>>>>> Made me think that Plan 9 for IoT system of systems could be viable.
>>>>>>>
>>>>>>> To that end, ESP-32 modules look capable enough to run Plan 9, but
>>>>>>> is there a Plan 9 C compiler for Xtensa ISA CPUs?
>>>>>>>
>>>>>>>

[-- Attachment #2: Type: text/html, Size: 7088 bytes --]

Re: [9fans] Plan 9 C compiler for Xtensa CPUs

[Shane Morris]

[-- Attachment #1: Type: text/plain, Size: 4037 bytes --]

Everything old is new again?

On Sat, Aug 10, 2019 at 7:11 PM Cyber Fonic <cyberfonic@gmail.com> wrote:

> The emergent problem with IoT is the lack of security.  From my
> understanding of Plan9's architecture. 9p protocol and the "root-less"
> security model suggests to me that a Plan9 swarm of IoT devices could be
> the "killer app" where Plan9 emerges on the strength of the vision of
> decades ago.  Looking at other RT OSes the security models are often bolted
> on.  Plan9 worked well on IBM PC era hardware. An ESP-32 has more resources
> and better networking than the early PCs.  From my tinkering and reverse
> engineering of IoT devices, almost all use 8266 based WiFi and often in
> conjunction with a uController. An ESP-32 is dual processor and with
> sufficient I/O for most simple tasks.  With IoT, in general, you don't need
> a lot of I/O, you simply throw more CPUs into the mix.
>
> On Sat, 10 Aug 2019 at 08:55, Skip Tavakkolian <skip.tavakkolian@gmail.com>
> wrote:
>
>> I'm not sure if the effort would be worth it; but if you add support for
>> esp32, I think it would be better for the os to be something like the one
>> you had in kencc for AVR (*) or possibly Russ' libtask, rather than Plan 9.
>> Staying with FreeRTOS would need removal of GCC specific things from OS and
>> dealing with lots of drivers in C++.
>>
>> The Cortex-M based mpus (e.g. Teensy 4 with Cortex M7 @ 600MHz) seem more
>> appropriate for an "embedded" Plan 9.
>>
>> (*) for those who have not seen it, it is here:
>> % ls -l /n/sources/contrib/forsyth/avr*
>> --rw-rw-r-- M 518 bootes sys 251227 Sep  4  2011
>> /n/sources/contrib/forsyth/avr.9gz
>>
>> On Fri, Aug 9, 2019 at 2:36 PM Charles Forsyth <charles.forsyth@gmail.com>
>> wrote:
>>
>>> Since the resources are small if not tiny, a little systems analysis and
>>> design is probably needed, but it looks like a bit of fun, until the
>>> inevitable moment of "why am I here?".
>>>
>>> On Fri, Aug 9, 2019 at 4:50 PM Charles Forsyth <
>>> charles.forsyth@gmail.com> wrote:
>>>
>>>> The device I've got is ESP32-WROOM-32. None of the boards I've seen
>>>> that use it bother with external memory,
>>>> so memory is limited, especially the way it's partitioned.
>>>>
>>>> On Fri, Aug 9, 2019 at 3:50 PM Charles Forsyth <
>>>> charles.forsyth@gmail.com> wrote:
>>>>
>>>>> The ESP32 has got several MMUs. The characteristics are different
>>>>> depending on the part that a given MMU accesses (flash, ROM, SRAM, external
>>>>> memory).
>>>>> Some things are accessed using Memory Protection Units instead, which
>>>>> control access by Process ID, but don't do mapping. Others including some
>>>>> of the SRAMs are accessed through
>>>>> an MMU that can do virtual to physical mapping. The MMUs for internal
>>>>> SRAM0 and 2 choose protection for a given physical page as none, one or all
>>>>> of PIDs 2 to 7, with the virtual address that
>>>>> maps to it. PIDs 0 and 1 can access everything. PID 0 can execute
>>>>> privileged instructions.
>>>>> A large chunk of SRAM (SRAM 1) has only Memory Protection and no
>>>>> translation. The external memory MMU is the most general (most
>>>>> conventional).
>>>>>
>>>>> On Fri, Aug 9, 2019 at 3:19 PM Bakul Shah <bakul@bitblocks.com> wrote:
>>>>>
>>>>>> esp32 doesn’t have an mmu, right?
>>>>>>
>>>>>> On Jul 26, 2019, at 03:30, Charles Forsyth <charles.forsyth@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> I was thinking of doing that since I've got an ESP-32 for some reason
>>>>>>
>>>>>> On Fri, Jul 26, 2019 at 7:38 AM Cyber Fonic <cyberfonic@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I was reading the post Why Didn't Plan 9 Succeed
>>>>>>> <https://news.ycombinator.com/item?id=20527650> on Hacker News.
>>>>>>>
>>>>>>> Made me think that Plan 9 for IoT system of systems could be viable.
>>>>>>>
>>>>>>> To that end, ESP-32 modules look capable enough to run Plan 9, but
>>>>>>> is there a Plan 9 C compiler for Xtensa ISA CPUs?
>>>>>>>
>>>>>>>

[-- Attachment #2: Type: text/html, Size: 6201 bytes --]

Re: [9fans] Plan 9 C compiler for Xtensa CPUs

[Cyber Fonic]

[-- Attachment #1: Type: text/plain, Size: 3832 bytes --]

The emergent problem with IoT is the lack of security.  From my
understanding of Plan9's architecture. 9p protocol and the "root-less"
security model suggests to me that a Plan9 swarm of IoT devices could be
the "killer app" where Plan9 emerges on the strength of the vision of
decades ago.  Looking at other RT OSes the security models are often bolted
on.  Plan9 worked well on IBM PC era hardware. An ESP-32 has more resources
and better networking than the early PCs.  From my tinkering and reverse
engineering of IoT devices, almost all use 8266 based WiFi and often in
conjunction with a uController. An ESP-32 is dual processor and with
sufficient I/O for most simple tasks.  With IoT, in general, you don't need
a lot of I/O, you simply throw more CPUs into the mix.

On Sat, 10 Aug 2019 at 08:55, Skip Tavakkolian <skip.tavakkolian@gmail.com>
wrote:

> I'm not sure if the effort would be worth it; but if you add support for
> esp32, I think it would be better for the os to be something like the one
> you had in kencc for AVR (*) or possibly Russ' libtask, rather than Plan 9.
> Staying with FreeRTOS would need removal of GCC specific things from OS and
> dealing with lots of drivers in C++.
>
> The Cortex-M based mpus (e.g. Teensy 4 with Cortex M7 @ 600MHz) seem more
> appropriate for an "embedded" Plan 9.
>
> (*) for those who have not seen it, it is here:
> % ls -l /n/sources/contrib/forsyth/avr*
> --rw-rw-r-- M 518 bootes sys 251227 Sep  4  2011
> /n/sources/contrib/forsyth/avr.9gz
>
> On Fri, Aug 9, 2019 at 2:36 PM Charles Forsyth <charles.forsyth@gmail.com>
> wrote:
>
>> Since the resources are small if not tiny, a little systems analysis and
>> design is probably needed, but it looks like a bit of fun, until the
>> inevitable moment of "why am I here?".
>>
>> On Fri, Aug 9, 2019 at 4:50 PM Charles Forsyth <charles.forsyth@gmail.com>
>> wrote:
>>
>>> The device I've got is ESP32-WROOM-32. None of the boards I've seen that
>>> use it bother with external memory,
>>> so memory is limited, especially the way it's partitioned.
>>>
>>> On Fri, Aug 9, 2019 at 3:50 PM Charles Forsyth <
>>> charles.forsyth@gmail.com> wrote:
>>>
>>>> The ESP32 has got several MMUs. The characteristics are different
>>>> depending on the part that a given MMU accesses (flash, ROM, SRAM, external
>>>> memory).
>>>> Some things are accessed using Memory Protection Units instead, which
>>>> control access by Process ID, but don't do mapping. Others including some
>>>> of the SRAMs are accessed through
>>>> an MMU that can do virtual to physical mapping. The MMUs for internal
>>>> SRAM0 and 2 choose protection for a given physical page as none, one or all
>>>> of PIDs 2 to 7, with the virtual address that
>>>> maps to it. PIDs 0 and 1 can access everything. PID 0 can execute
>>>> privileged instructions.
>>>> A large chunk of SRAM (SRAM 1) has only Memory Protection and no
>>>> translation. The external memory MMU is the most general (most
>>>> conventional).
>>>>
>>>> On Fri, Aug 9, 2019 at 3:19 PM Bakul Shah <bakul@bitblocks.com> wrote:
>>>>
>>>>> esp32 doesn’t have an mmu, right?
>>>>>
>>>>> On Jul 26, 2019, at 03:30, Charles Forsyth <charles.forsyth@gmail.com>
>>>>> wrote:
>>>>>
>>>>> I was thinking of doing that since I've got an ESP-32 for some reason
>>>>>
>>>>> On Fri, Jul 26, 2019 at 7:38 AM Cyber Fonic <cyberfonic@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> I was reading the post Why Didn't Plan 9 Succeed
>>>>>> <https://news.ycombinator.com/item?id=20527650> on Hacker News.
>>>>>>
>>>>>> Made me think that Plan 9 for IoT system of systems could be viable.
>>>>>>
>>>>>> To that end, ESP-32 modules look capable enough to run Plan 9, but is
>>>>>> there a Plan 9 C compiler for Xtensa ISA CPUs?
>>>>>>
>>>>>>

[-- Attachment #2: Type: text/html, Size: 5796 bytes --]

Re: [9fans] Plan 9 C compiler for Xtensa CPUs

[Skip Tavakkolian]

[-- Attachment #1: Type: text/plain, Size: 2876 bytes --]

I'm not sure if the effort would be worth it; but if you add support for
esp32, I think it would be better for the os to be something like the one
you had in kencc for AVR (*) or possibly Russ' libtask, rather than Plan 9.
Staying with FreeRTOS would need removal of GCC specific things from OS and
dealing with lots of drivers in C++.

The Cortex-M based mpus (e.g. Teensy 4 with Cortex M7 @ 600MHz) seem more
appropriate for an "embedded" Plan 9.

(*) for those who have not seen it, it is here:
% ls -l /n/sources/contrib/forsyth/avr*
--rw-rw-r-- M 518 bootes sys 251227 Sep  4  2011
/n/sources/contrib/forsyth/avr.9gz

On Fri, Aug 9, 2019 at 2:36 PM Charles Forsyth <charles.forsyth@gmail.com>
wrote:

> Since the resources are small if not tiny, a little systems analysis and
> design is probably needed, but it looks like a bit of fun, until the
> inevitable moment of "why am I here?".
>
> On Fri, Aug 9, 2019 at 4:50 PM Charles Forsyth <charles.forsyth@gmail.com>
> wrote:
>
>> The device I've got is ESP32-WROOM-32. None of the boards I've seen that
>> use it bother with external memory,
>> so memory is limited, especially the way it's partitioned.
>>
>> On Fri, Aug 9, 2019 at 3:50 PM Charles Forsyth <charles.forsyth@gmail.com>
>> wrote:
>>
>>> The ESP32 has got several MMUs. The characteristics are different
>>> depending on the part that a given MMU accesses (flash, ROM, SRAM, external
>>> memory).
>>> Some things are accessed using Memory Protection Units instead, which
>>> control access by Process ID, but don't do mapping. Others including some
>>> of the SRAMs are accessed through
>>> an MMU that can do virtual to physical mapping. The MMUs for internal
>>> SRAM0 and 2 choose protection for a given physical page as none, one or all
>>> of PIDs 2 to 7, with the virtual address that
>>> maps to it. PIDs 0 and 1 can access everything. PID 0 can execute
>>> privileged instructions.
>>> A large chunk of SRAM (SRAM 1) has only Memory Protection and no
>>> translation. The external memory MMU is the most general (most
>>> conventional).
>>>
>>> On Fri, Aug 9, 2019 at 3:19 PM Bakul Shah <bakul@bitblocks.com> wrote:
>>>
>>>> esp32 doesn’t have an mmu, right?
>>>>
>>>> On Jul 26, 2019, at 03:30, Charles Forsyth <charles.forsyth@gmail.com>
>>>> wrote:
>>>>
>>>> I was thinking of doing that since I've got an ESP-32 for some reason
>>>>
>>>> On Fri, Jul 26, 2019 at 7:38 AM Cyber Fonic <cyberfonic@gmail.com>
>>>> wrote:
>>>>
>>>>> I was reading the post Why Didn't Plan 9 Succeed
>>>>> <https://news.ycombinator.com/item?id=20527650> on Hacker News.
>>>>>
>>>>> Made me think that Plan 9 for IoT system of systems could be viable.
>>>>>
>>>>> To that end, ESP-32 modules look capable enough to run Plan 9, but is
>>>>> there a Plan 9 C compiler for Xtensa ISA CPUs?
>>>>>
>>>>>

[-- Attachment #2: Type: text/html, Size: 4601 bytes --]

Re: [9fans] Plan 9 C compiler for Xtensa CPUs

[Bakul Shah]

On Aug 9, 2019, at 2:34 PM, Charles Forsyth <charles.forsyth@gmail.com> wrote:
> 
> Since the resources are small if not tiny, a little systems analysis and design is probably needed, but it looks like a bit of fun, until the inevitable moment of "why am I here?".
> 
> On Fri, Aug 9, 2019 at 4:50 PM Charles Forsyth <charles.forsyth@gmail.com> wrote:
> The device I've got is ESP32-WROOM-32. None of the boards I've seen that use it bother with external memory,
> so memory is limited, especially the way it's partitioned.
> 
> On Fri, Aug 9, 2019 at 3:50 PM Charles Forsyth <charles.forsyth@gmail.com> wrote:
> The ESP32 has got several MMUs. The characteristics are different depending on the part that a given MMU accesses (flash, ROM, SRAM, external memory).
> Some things are accessed using Memory Protection Units instead, which control access by Process ID, but don't do mapping. Others including some of the SRAMs are accessed through
> an MMU that can do virtual to physical mapping. The MMUs for internal SRAM0 and 2 choose protection for a given physical page as none, one or all of PIDs 2 to 7, with the virtual address that
> maps to it. PIDs 0 and 1 can access everything. PID 0 can execute privileged instructions.
> A large chunk of SRAM (SRAM 1) has only Memory Protection and no translation. The external memory MMU is the most general (most conventional).

Thanks.

Not ideal for plan9 but it would be nice to have access to all its IO capabilities over 9p.

Re: [9fans] Plan 9 C compiler for Xtensa CPUs

[Shane Morris]

[-- Attachment #1: Type: text/plain, Size: 2308 bytes --]

Wireless NinePea perhaps?

https://github.com/echoline/NinePea

On Sat, Aug 10, 2019 at 7:36 AM Charles Forsyth <charles.forsyth@gmail.com>
wrote:

> Since the resources are small if not tiny, a little systems analysis and
> design is probably needed, but it looks like a bit of fun, until the
> inevitable moment of "why am I here?".
>
> On Fri, Aug 9, 2019 at 4:50 PM Charles Forsyth <charles.forsyth@gmail.com>
> wrote:
>
>> The device I've got is ESP32-WROOM-32. None of the boards I've seen that
>> use it bother with external memory,
>> so memory is limited, especially the way it's partitioned.
>>
>> On Fri, Aug 9, 2019 at 3:50 PM Charles Forsyth <charles.forsyth@gmail.com>
>> wrote:
>>
>>> The ESP32 has got several MMUs. The characteristics are different
>>> depending on the part that a given MMU accesses (flash, ROM, SRAM, external
>>> memory).
>>> Some things are accessed using Memory Protection Units instead, which
>>> control access by Process ID, but don't do mapping. Others including some
>>> of the SRAMs are accessed through
>>> an MMU that can do virtual to physical mapping. The MMUs for internal
>>> SRAM0 and 2 choose protection for a given physical page as none, one or all
>>> of PIDs 2 to 7, with the virtual address that
>>> maps to it. PIDs 0 and 1 can access everything. PID 0 can execute
>>> privileged instructions.
>>> A large chunk of SRAM (SRAM 1) has only Memory Protection and no
>>> translation. The external memory MMU is the most general (most
>>> conventional).
>>>
>>> On Fri, Aug 9, 2019 at 3:19 PM Bakul Shah <bakul@bitblocks.com> wrote:
>>>
>>>> esp32 doesn’t have an mmu, right?
>>>>
>>>> On Jul 26, 2019, at 03:30, Charles Forsyth <charles.forsyth@gmail.com>
>>>> wrote:
>>>>
>>>> I was thinking of doing that since I've got an ESP-32 for some reason
>>>>
>>>> On Fri, Jul 26, 2019 at 7:38 AM Cyber Fonic <cyberfonic@gmail.com>
>>>> wrote:
>>>>
>>>>> I was reading the post Why Didn't Plan 9 Succeed
>>>>> <https://news.ycombinator.com/item?id=20527650> on Hacker News.
>>>>>
>>>>> Made me think that Plan 9 for IoT system of systems could be viable.
>>>>>
>>>>> To that end, ESP-32 modules look capable enough to run Plan 9, but is
>>>>> there a Plan 9 C compiler for Xtensa ISA CPUs?
>>>>>
>>>>>

[-- Attachment #2: Type: text/html, Size: 4040 bytes --]

Re: [9fans] Plan 9 C compiler for Xtensa CPUs

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 2098 bytes --]

Since the resources are small if not tiny, a little systems analysis and
design is probably needed, but it looks like a bit of fun, until the
inevitable moment of "why am I here?".

On Fri, Aug 9, 2019 at 4:50 PM Charles Forsyth <charles.forsyth@gmail.com>
wrote:

> The device I've got is ESP32-WROOM-32. None of the boards I've seen that
> use it bother with external memory,
> so memory is limited, especially the way it's partitioned.
>
> On Fri, Aug 9, 2019 at 3:50 PM Charles Forsyth <charles.forsyth@gmail.com>
> wrote:
>
>> The ESP32 has got several MMUs. The characteristics are different
>> depending on the part that a given MMU accesses (flash, ROM, SRAM, external
>> memory).
>> Some things are accessed using Memory Protection Units instead, which
>> control access by Process ID, but don't do mapping. Others including some
>> of the SRAMs are accessed through
>> an MMU that can do virtual to physical mapping. The MMUs for internal
>> SRAM0 and 2 choose protection for a given physical page as none, one or all
>> of PIDs 2 to 7, with the virtual address that
>> maps to it. PIDs 0 and 1 can access everything. PID 0 can execute
>> privileged instructions.
>> A large chunk of SRAM (SRAM 1) has only Memory Protection and no
>> translation. The external memory MMU is the most general (most
>> conventional).
>>
>> On Fri, Aug 9, 2019 at 3:19 PM Bakul Shah <bakul@bitblocks.com> wrote:
>>
>>> esp32 doesn’t have an mmu, right?
>>>
>>> On Jul 26, 2019, at 03:30, Charles Forsyth <charles.forsyth@gmail.com>
>>> wrote:
>>>
>>> I was thinking of doing that since I've got an ESP-32 for some reason
>>>
>>> On Fri, Jul 26, 2019 at 7:38 AM Cyber Fonic <cyberfonic@gmail.com>
>>> wrote:
>>>
>>>> I was reading the post Why Didn't Plan 9 Succeed
>>>> <https://news.ycombinator.com/item?id=20527650> on Hacker News.
>>>>
>>>> Made me think that Plan 9 for IoT system of systems could be viable.
>>>>
>>>> To that end, ESP-32 modules look capable enough to run Plan 9, but is
>>>> there a Plan 9 C compiler for Xtensa ISA CPUs?
>>>>
>>>>

[-- Attachment #2: Type: text/html, Size: 3506 bytes --]

Re: [9fans] Plan 9 C compiler for Xtensa CPUs

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 1774 bytes --]

The device I've got is ESP32-WROOM-32. None of the boards I've seen that
use it bother with external memory,
so memory is limited, especially the way it's partitioned.

On Fri, Aug 9, 2019 at 3:50 PM Charles Forsyth <charles.forsyth@gmail.com>
wrote:

> The ESP32 has got several MMUs. The characteristics are different
> depending on the part that a given MMU accesses (flash, ROM, SRAM, external
> memory).
> Some things are accessed using Memory Protection Units instead, which
> control access by Process ID, but don't do mapping. Others including some
> of the SRAMs are accessed through
> an MMU that can do virtual to physical mapping. The MMUs for internal
> SRAM0 and 2 choose protection for a given physical page as none, one or all
> of PIDs 2 to 7, with the virtual address that
> maps to it. PIDs 0 and 1 can access everything. PID 0 can execute
> privileged instructions.
> A large chunk of SRAM (SRAM 1) has only Memory Protection and no
> translation. The external memory MMU is the most general (most
> conventional).
>
> On Fri, Aug 9, 2019 at 3:19 PM Bakul Shah <bakul@bitblocks.com> wrote:
>
>> esp32 doesn’t have an mmu, right?
>>
>> On Jul 26, 2019, at 03:30, Charles Forsyth <charles.forsyth@gmail.com>
>> wrote:
>>
>> I was thinking of doing that since I've got an ESP-32 for some reason
>>
>> On Fri, Jul 26, 2019 at 7:38 AM Cyber Fonic <cyberfonic@gmail.com> wrote:
>>
>>> I was reading the post Why Didn't Plan 9 Succeed
>>> <https://news.ycombinator.com/item?id=20527650> on Hacker News.
>>>
>>> Made me think that Plan 9 for IoT system of systems could be viable.
>>>
>>> To that end, ESP-32 modules look capable enough to run Plan 9, but is
>>> there a Plan 9 C compiler for Xtensa ISA CPUs?
>>>
>>>

[-- Attachment #2: Type: text/html, Size: 2930 bytes --]

Re: [9fans] Plan 9 C compiler for Xtensa CPUs

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 1464 bytes --]

The ESP32 has got several MMUs. The characteristics are different depending
on the part that a given MMU accesses (flash, ROM, SRAM, external memory).
Some things are accessed using Memory Protection Units instead, which
control access by Process ID, but don't do mapping. Others including some
of the SRAMs are accessed through
an MMU that can do virtual to physical mapping. The MMUs for internal SRAM0
and 2 choose protection for a given physical page as none, one or all of
PIDs 2 to 7, with the virtual address that
maps to it. PIDs 0 and 1 can access everything. PID 0 can execute
privileged instructions.
A large chunk of SRAM (SRAM 1) has only Memory Protection and no
translation. The external memory MMU is the most general (most
conventional).

On Fri, Aug 9, 2019 at 3:19 PM Bakul Shah <bakul@bitblocks.com> wrote:

> esp32 doesn’t have an mmu, right?
>
> On Jul 26, 2019, at 03:30, Charles Forsyth <charles.forsyth@gmail.com>
> wrote:
>
> I was thinking of doing that since I've got an ESP-32 for some reason
>
> On Fri, Jul 26, 2019 at 7:38 AM Cyber Fonic <cyberfonic@gmail.com> wrote:
>
>> I was reading the post Why Didn't Plan 9 Succeed
>> <https://news.ycombinator.com/item?id=20527650> on Hacker News.
>>
>> Made me think that Plan 9 for IoT system of systems could be viable.
>>
>> To that end, ESP-32 modules look capable enough to run Plan 9, but is
>> there a Plan 9 C compiler for Xtensa ISA CPUs?
>>
>>

[-- Attachment #2: Type: text/html, Size: 2355 bytes --]

Re: [9fans] Plan 9 C compiler for Xtensa CPUs

[Bakul Shah]

[-- Attachment #1: Type: text/plain, Size: 558 bytes --]

esp32 doesn’t have an mmu, right?

> On Jul 26, 2019, at 03:30, Charles Forsyth <charles.forsyth@gmail.com> wrote:
> 
> I was thinking of doing that since I've got an ESP-32 for some reason
> 
>> On Fri, Jul 26, 2019 at 7:38 AM Cyber Fonic <cyberfonic@gmail.com> wrote:
>> I was reading the post Why Didn't Plan 9 Succeed on Hacker News.
>> 
>> Made me think that Plan 9 for IoT system of systems could be viable.
>> 
>> To that end, ESP-32 modules look capable enough to run Plan 9, but is there a Plan 9 C compiler for Xtensa ISA CPUs? 
>> 

[-- Attachment #2: Type: text/html, Size: 1271 bytes --]

Re: [9fans] Plan 9 C compiler for Xtensa CPUs

[Lucio De Re]

On 8/7/19, Charles Forsyth <charles.forsyth@gmail.com> wrote:
> I've not previously seen an architecture where so many cache and TLB
> control instructions were in the primary space and took up so much of it.
>
I guess the remainder is RISC :-).

Lucio.

Re: [9fans] Plan 9 C compiler for Xtensa CPUs

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 728 bytes --]

I've not previously seen an architecture where so many cache and TLB
control instructions were in the primary space and took up so much of it.


On Fri, Jul 26, 2019 at 11:30 AM Charles Forsyth <charles.forsyth@gmail.com>
wrote:

> I was thinking of doing that since I've got an ESP-32 for some reason
>
> On Fri, Jul 26, 2019 at 7:38 AM Cyber Fonic <cyberfonic@gmail.com> wrote:
>
>> I was reading the post Why Didn't Plan 9 Succeed
>> <https://news.ycombinator.com/item?id=20527650> on Hacker News.
>>
>> Made me think that Plan 9 for IoT system of systems could be viable.
>>
>> To that end, ESP-32 modules look capable enough to run Plan 9, but is
>> there a Plan 9 C compiler for Xtensa ISA CPUs?
>>
>>

[-- Attachment #2: Type: text/html, Size: 1401 bytes --]

Re: [9fans] Plan 9 C compiler for Xtensa CPUs

[Anthony Martin]

Richard Miller <9fans@hamnavoe.com> once said:
> I see the above list uses .e and .j for riscv and riscv64 -
> are these just reserved or are there actual compilers somewhere?

No, it was just a suggestion on my part. If I remember correctly,
I thought it was mildly clever that 'e' is the fifth letter in the
English alphabet and 'j' is five letters after that.

I'm only aware of your riscv compiler.

  Anthony

Re: [9fans] Plan 9 C compiler for Xtensa CPUs

[Richard Miller]

> https://www.pbrane.org/comp.html

I've used .x for riscv32 but it's easily changed.

I see the above list uses .e and .j for riscv and riscv64 -
are these just reserved or are there actual compilers somewhere?

Re: [9fans] Plan 9 C compiler for Xtensa CPUs

[Anthony Martin]

Charles Forsyth <charles.forsyth@gmail.com> once said:
> I'd need a letter or number and thought about reusing x (xa/xc/xl) since
> the AT&T DSP is long gone

https://github.com/0intro/plan9-mips/tree/master/sys/src/cmd/4c
https://github.com/0intro/plan9-mips/blob/master/rc/bin/xc

I think I sent this to the list once before but here's a table that I made
a while back.

https://www.pbrane.org/comp.html

The number 3 is free.

Cheers,
  Anthony

Re: [9fans] Plan 9 C compiler for Xtensa CPUs

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 682 bytes --]

I'd need a letter or number and thought about reusing x (xa/xc/xl) since
the AT&T DSP is long gone

On Fri, Jul 26, 2019 at 11:30 AM Charles Forsyth <charles.forsyth@gmail.com>
wrote:

> I was thinking of doing that since I've got an ESP-32 for some reason
>
> On Fri, Jul 26, 2019 at 7:38 AM Cyber Fonic <cyberfonic@gmail.com> wrote:
>
>> I was reading the post Why Didn't Plan 9 Succeed
>> <https://news.ycombinator.com/item?id=20527650> on Hacker News.
>>
>> Made me think that Plan 9 for IoT system of systems could be viable.
>>
>> To that end, ESP-32 modules look capable enough to run Plan 9, but is
>> there a Plan 9 C compiler for Xtensa ISA CPUs?
>>
>>

[-- Attachment #2: Type: text/html, Size: 1362 bytes --]

Re: [9fans] Plan 9 C compiler for Xtensa CPUs

[cinap_lenrek]

nope. charles is your man.

--
cinap

Re: [9fans] Plan 9 C compiler for Xtensa CPUs

[Cyber Fonic]

[-- Attachment #1: Type: text/plain, Size: 1066 bytes --]

Does anybody have any suggestions as to what it would take to create a C
compiler for Xtensa (it is basically a 32 bit sorta-like RISC architecture)?

Since C compilers do exist for Xtensa (both Arduino and ESIF) , is it at
all possible to port Plan 9 C compilers using a "host" compiler as a
semi-bootstrap?

Or would it be more effectively to use an existing Plan 9 system, grab the
sources for a similar compiler, e.g. MIPS and start building a Xtensa /
ESP-32 specific one?

On Fri, 26 Jul 2019 at 20:31, Charles Forsyth <charles.forsyth@gmail.com>
wrote:

> I was thinking of doing that since I've got an ESP-32 for some reason
>
> On Fri, Jul 26, 2019 at 7:38 AM Cyber Fonic <cyberfonic@gmail.com> wrote:
>
>> I was reading the post Why Didn't Plan 9 Succeed
>> <https://news.ycombinator.com/item?id=20527650> on Hacker News.
>>
>> Made me think that Plan 9 for IoT system of systems could be viable.
>>
>> To that end, ESP-32 modules look capable enough to run Plan 9, but is
>> there a Plan 9 C compiler for Xtensa ISA CPUs?
>>
>>

[-- Attachment #2: Type: text/html, Size: 1772 bytes --]

Re: [9fans] Plan 9 C compiler for Xtensa CPUs

[Rodrigo G. López]

[-- Attachment #1: Type: text/plain, Size: 748 bytes --]

you are one of the few who could pull that off.
the alternative would be to send the board to cinap, and he'd probably
deploy a compiler+kernel in a couple of weeks.

On Fri, Jul 26, 2019, 12:31 PM Charles Forsyth <charles.forsyth@gmail.com>
wrote:

> I was thinking of doing that since I've got an ESP-32 for some reason
>
> On Fri, Jul 26, 2019 at 7:38 AM Cyber Fonic <cyberfonic@gmail.com> wrote:
>
>> I was reading the post Why Didn't Plan 9 Succeed
>> <https://news.ycombinator.com/item?id=20527650> on Hacker News.
>>
>> Made me think that Plan 9 for IoT system of systems could be viable.
>>
>> To that end, ESP-32 modules look capable enough to run Plan 9, but is
>> there a Plan 9 C compiler for Xtensa ISA CPUs?
>>
>>

[-- Attachment #2: Type: text/html, Size: 1470 bytes --]

Re: [9fans] Plan 9 C compiler for Xtensa CPUs

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 476 bytes --]

I was thinking of doing that since I've got an ESP-32 for some reason

On Fri, Jul 26, 2019 at 7:38 AM Cyber Fonic <cyberfonic@gmail.com> wrote:

> I was reading the post Why Didn't Plan 9 Succeed
> <https://news.ycombinator.com/item?id=20527650> on Hacker News.
>
> Made me think that Plan 9 for IoT system of systems could be viable.
>
> To that end, ESP-32 modules look capable enough to run Plan 9, but is
> there a Plan 9 C compiler for Xtensa ISA CPUs?
>
>

[-- Attachment #2: Type: text/html, Size: 852 bytes --]

Re: [9fans] Plan 9 C compiler for Xtensa CPUs

[Rodrigo G. López]

[-- Attachment #1: Type: text/plain, Size: 463 bytes --]

there is not.

contributions are welcome. :)


-rodri

On Fri, Jul 26, 2019, 8:38 AM Cyber Fonic <cyberfonic@gmail.com> wrote:

> I was reading the post Why Didn't Plan 9 Succeed
> <https://news.ycombinator.com/item?id=20527650> on Hacker News.
>
> Made me think that Plan 9 for IoT system of systems could be viable.
>
> To that end, ESP-32 modules look capable enough to run Plan 9, but is
> there a Plan 9 C compiler for Xtensa ISA CPUs?
>
>

[-- Attachment #2: Type: text/html, Size: 946 bytes --]

[9fans] Plan 9 C compiler for Xtensa CPUs

[Cyber Fonic]

[-- Attachment #1: Type: text/plain, Size: 308 bytes --]

I was reading the post Why Didn't Plan 9 Succeed
<https://news.ycombinator.com/item?id=20527650> on Hacker News.

Made me think that Plan 9 for IoT system of systems could be viable.

To that end, ESP-32 modules look capable enough to run Plan 9, but is there
a Plan 9 C compiler for Xtensa ISA CPUs?

[-- Attachment #2: Type: text/html, Size: 406 bytes --]