On Wednesday, June 30, 2021 at 9:04:29 AM UTC-6, MitchAlsup wrote:

> This goes into the YECH category. You are making DECODE dependent on the forwarding
> stage that occurs after DECODE.

That is an important point. If one is going to have an Execute instruction, does that
mean one will have to tie the pipeline up into knots in a way that will make *every*
instruction slower? If so, one definitely should not go there.

However, most architectures do have instructions that transfer control. Those certainly
make what gets decoded next dependent on the completion of the branch instruction.

So if one forces the Execute instruction to submit the instruction to be executed to the
decoder through the "front door", as it were, just like an instruction fetched from memory,
instead of attempting to create a faster "back door" for it, then one would get the desired
result: the Execute instruction might take an extra cycle or two, but its existence would
not impinge on how the pipeline works for everything else.

John Savard

I have wrapped up the EXEC instruction in #SUPPORT directives removing it from the arch since it is too slow and consumes too many resources.

I dove into supporting load and store multiple instructions LDM / STM. These instruction may have been implemented with micro-code on some machines.
Ultimately I chose to support them with the front-end doing a hidden branch back to the same instruction. The issue was two pipeline stages before decode. So it is unknown that there is an LDM / STM in the pipeline until after another instruction has been fetched. As implemented it will result in every other instruction queued being invalidated. There are probably better ways of implementing the instructions, but the way it is done is simple and does not require a lot of resources.

On Thursday, July 1, 2021 at 2:40:34 AM UTC-6, Quadibloc wrote:
> On Wednesday, June 30, 2021 at 9:04:29 AM UTC-6, MitchAlsup wrote:

> > This goes into the YECH category. You are making DECODE dependent on the forwarding
> > stage that occurs after DECODE.

> That is an important point. If one is going to have an Execute instruction, does that
> mean one will have to tie the pipeline up into knots in a way that will make *every*
> instruction slower? If so, one definitely should not go there.

> However, most architectures do have instructions that transfer control. Those certainly
> make what gets decoded next dependent on the completion of the branch instruction.

> So if one forces the Execute instruction to submit the instruction to be executed to the
> decoder through the "front door", as it were, just like an instruction fetched from memory,
> instead of attempting to create a faster "back door" for it, then one would get the desired
> result: the Execute instruction might take an extra cycle or two, but its existence would
> not impinge on how the pipeline works for everything else.

On further reflection, it may not be as simple as this, since instructions in the pipeline need
to be accompanied by information about where they came from - and _that_ could be
complicated unavoidably by the existence of an Execute instruction.

John Savard

According to Quadibloc <jsavard@ecn.ab.ca>:
>On Wednesday, June 30, 2021 at 7:50:50 PM UTC-6, MitchAlsup wrote:
>
>> In any event, these show that the instruction set was misconceived (at least originally)
>> and that if properly conceived EXC would not have been necessary.
>
>Although the most common use of the Execute instruction by ordinary programmers
>was to change the length of string operations, I don't think that's what it was intended
>for.

I'm quite sure they had that in mind. Why else would it modify the
second byte, and only the second byte, of the target instruction,
which is where the length field was? In Cobol and RPG programs, most
character operations take operands of known lengths, so putting the
length in the instruction saved a register reference in the usual
case, and the EX hack let them handle variable length strings while
keeping the code reentrant.

>I think they did put it in to have a way of making it easier to write routines that serviced
>an unimplemented opcode exception by causing the bad instruction to do something
>useful, thus extending the instruction set...

In a word, no. This was the 1960s, remember? IBM had no interest in
simulating the decimal or floating point instructions on machines that
didn't have them, since they wanted you to buy the upgrade. The high
end 360/91 did not have the decimal instructions so OS/360 simulated
them very slowly. I have heard that on CP/67 and VM/370 they
simulated instructions to be added to the next generation of hardware
so the software and hardware development could proceed in parallel.
Those were both pretty exotic.

In both of those cases the instruction caused an operation exception and a trap to the
operating system which had to check that the operand addresses were valid before it
could start to do the simulation. I cannot see that EX would have helped at all.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On Thursday, July 1, 2021 at 11:22:51 AM UTC-5, John Levine wrote:
> According to Quadibloc <jsa...@ecn.ab.ca>:
> >On Wednesday, June 30, 2021 at 7:50:50 PM UTC-6, MitchAlsup wrote:
> >
> >> In any event, these show that the instruction set was misconceived (at least originally)
> >> and that if properly conceived EXC would not have been necessary.
> >
> >Although the most common use of the Execute instruction by ordinary programmers
> >was to change the length of string operations, I don't think that's what it was intended
> >for.
<
> I'm quite sure they had that in mind. Why else would it modify the
> second byte, and only the second byte, of the target instruction,
> which is where the length field was? In Cobol and RPG programs, most
> character operations take operands of known lengths, so putting the
> length in the instruction saved a register reference in the usual
> case, and the EX hack let them handle variable length strings while
> keeping the code reentrant.
<
I am sure this was the intent, also,
<
However, a better solution would have been for the preceding instruction
to announce that it has the variable length for the subsequent instruction
and then there is no need for EXC. This is effectively what I do with CARRY
and PRED, and to a certain extent VEC-LOOP.
<
> >I think they did put it in to have a way of making it easier to write routines that serviced
> >an unimplemented opcode exception by causing the bad instruction to do something
> >useful, thus extending the instruction set...
> In a word, no. This was the 1960s, remember? IBM had no interest in
> simulating the decimal or floating point instructions on machines that
> didn't have them, since they wanted you to buy the upgrade. The high
> end 360/91 did not have the decimal instructions so OS/360 simulated
> them very slowly. I have heard that on CP/67 and VM/370 they
> simulated instructions to be added to the next generation of hardware
> so the software and hardware development could proceed in parallel.
> Those were both pretty exotic.
>
> In both of those cases the instruction caused an operation exception and a trap to the
> operating system which had to check that the operand addresses were valid before it
> could start to do the simulation. I cannot see that EX would have helped at all.
> --
> Regards,
> John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly

On 7/1/2021 11:33 AM, MitchAlsup wrote:
> On Thursday, July 1, 2021 at 11:22:51 AM UTC-5, John Levine wrote:
>> According to Quadibloc <jsa...@ecn.ab.ca>:
>>> On Wednesday, June 30, 2021 at 7:50:50 PM UTC-6, MitchAlsup wrote:
>>>
>>>> In any event, these show that the instruction set was misconceived (at least originally)
>>>> and that if properly conceived EXC would not have been necessary.
>>>
>>> Although the most common use of the Execute instruction by ordinary programmers
>>> was to change the length of string operations, I don't think that's what it was intended
>>> for.
> <
>> I'm quite sure they had that in mind. Why else would it modify the
>> second byte, and only the second byte, of the target instruction,
>> which is where the length field was? In Cobol and RPG programs, most
>> character operations take operands of known lengths, so putting the
>> length in the instruction saved a register reference in the usual
>> case, and the EX hack let them handle variable length strings while
>> keeping the code reentrant.
> <
> I am sure this was the intent, also,
> <
> However, a better solution would have been for the preceding instruction
> to announce that it has the variable length for the subsequent instruction
> and then there is no need for EXC. This is effectively what I do with CARRY
> and PRED, and to a certain extent VEC-LOOP.

Perhaps. Then they would have to have added that information to the
PSW, as they didn't have the luxury of a large context save area with
the fast mechanism that you have of context switches. And I am not sure
it would have fitted in the then existing PSW, which would have required
a more significant change.

While I agree that you have a better solution, I apparently have more
sympathy for the early 1960s designers.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On 7/1/2021 11:33 AM, MitchAlsup wrote:
> On Thursday, July 1, 2021 at 11:22:51 AM UTC-5, John Levine wrote:
>> According to Quadibloc <jsa...@ecn.ab.ca>:
>>> On Wednesday, June 30, 2021 at 7:50:50 PM UTC-6, MitchAlsup wrote:
>>>
>>>> In any event, these show that the instruction set was misconceived (at least originally)
>>>> and that if properly conceived EXC would not have been necessary.
>>>
>>> Although the most common use of the Execute instruction by ordinary programmers
>>> was to change the length of string operations, I don't think that's what it was intended
>>> for.
> <
>> I'm quite sure they had that in mind. Why else would it modify the
>> second byte, and only the second byte, of the target instruction,
>> which is where the length field was? In Cobol and RPG programs, most
>> character operations take operands of known lengths, so putting the
>> length in the instruction saved a register reference in the usual
>> case, and the EX hack let them handle variable length strings while
>> keeping the code reentrant.
> <
> I am sure this was the intent, also,
> <
> However, a better solution would have been for the preceding instruction
> to announce that it has the variable length for the subsequent instruction
> and then there is no need for EXC. This is effectively what I do with CARRY
> and PRED, and to a certain extent VEC-LOOP.

Or for bundle-based encodings, the extra bits can be in an adjacent slot
in the bundle, which we call "ganging".

In article <8b1baea3-a802-4341-8afd-d827e4eee948n@googlegroups.com>,
MitchAlsup <MitchAlsup@aol.com> wrote:
>On Saturday, June 26, 2021 at 10:54:53 AM UTC-5, EricP wrote:
>> MitchAlsup wrote:
>> > <
>> > To show the extent of my disfavor for EXC, in My 66000 one cannot
>execute code in a page
>> > that is writable !
>> That forces JIT'ers and self modifiers to make a trip through
>> the OS to change the page protection from RW to RE.
><
>No, it requires the JIT to run in a different address mapping than the
>application
>using the JITted code. Since this transition only costs 12 cycles plus cache
>effects, it is well worth while.
><
>> Not that it is a bad thing as it does allow the OS to clean up model
>> specfic things like caches and prefetch buffers across multiple SMP cores.

Can you explain why you're doing this? What does having the JIT modification
be in a different address space help in the hardware? I'm not seeing how
this really helps, other than to make certain JIT strategies harder.

It also appears to make verification harder with out making the
hardware cases go away--another thread (or this thread, with a different
mapping) can still change code that is actively being executed, so you
have to handle that case still. What is your synchronization strategy?

Kent

On Thursday, July 1, 2021 at 1:12:15 PM UTC-6, Stephen Fuld wrote:
> On 7/1/2021 11:33 AM, MitchAlsup wrote:

> > However, a better solution would have been for the preceding instruction
> > to announce that it has the variable length for the subsequent instruction
> > and then there is no need for EXC. This is effectively what I do with CARRY
> > and PRED, and to a certain extent VEC-LOOP.

> Perhaps. Then they would have to have added that information to the
> PSW, as they didn't have the luxury of a large context save area with
> the fast mechanism that you have of context switches. And I am not sure
> it would have fitted in the then existing PSW, which would have required
> a more significant change.

> While I agree that you have a better solution, I apparently have more
> sympathy for the early 1960s designers.

Indeed, you have pinpointed the issue with his "better solution" - it creates state.

Now, though, one doesn't _have_ to put the state in an elarged PSW. What Mitch
Alsup was probably envisaging is that the preceding instruction plus at least the
decode of the following instlruction would be *atomic* - if it can't be interrupted,
then nothing needs to be saved.

The trouble with that, though, is it adds a complexity to the architecture which is
a problem for the "early 1960s designers" who were making the very low-end models
in the 360 series. Or maybe not; maybe not having instructions *strictly* follow the
one-two-three halfword lengths that they officially have is not a problem when you're
doing everything in microcode, so it's the 360/75 and the 360/44, and the 360/91 that
would have come a cropper.

John Savard

On Thursday, July 1, 2021 at 8:39:10 PM UTC-5, Kent Dickey wrote:
> In article <8b1baea3-a802-4341...@googlegroups.com>,
> MitchAlsup <Mitch...@aol.com> wrote:
> >On Saturday, June 26, 2021 at 10:54:53 AM UTC-5, EricP wrote:
> >> MitchAlsup wrote:
> >> > <
> >> > To show the extent of my disfavor for EXC, in My 66000 one cannot
> >execute code in a page
> >> > that is writable !
> >> That forces JIT'ers and self modifiers to make a trip through
> >> the OS to change the page protection from RW to RE.
> ><
> >No, it requires the JIT to run in a different address mapping than the
> >application
> >using the JITted code. Since this transition only costs 12 cycles plus cache
> >effects, it is well worth while.
> ><
> >> Not that it is a bad thing as it does allow the OS to clean up model
> >> specfic things like caches and prefetch buffers across multiple SMP cores.
>
> Can you explain why you're doing this? What does having the JIT modification
> be in a different address space help in the hardware? I'm not seeing how
> this really helps, other than to make certain JIT strategies harder.
<
Protection::
The executor of the code cannot modify the code (no write permission).
The JIT is not in the address space of the "application"
The "application" cannot modify the JITer or even see it
The "application" can only see the ASCII code given to the JIT.
The "application" can only execute from JIT cache.
Thus:: JIT smells a lot more like a dynamic library than current.
>
> It also appears to make verification harder with out making the
> hardware cases go away--another thread (or this thread, with a different
> mapping) can still change code that is actively being executed, so you
> have to handle that case still. What is your synchronization strategy?
<
With variable length instructions it is "extremely bad" if part of the inst
has been put in JIT cache and the rest has not. Likewise, it is bad if
sensibly incomplete codes are put in JIT cache.
<
JIT pauses consuming applications during JITification and restarts them
afterwards.
<
Also note: one can pause a number of "tasks" with a single My 66000 inst
and likewise, those tasks can be restarted with a single inst.
So the overhead of doing this is not what your intuition imagines.
>
> Kent

On Thursday, July 1, 2021 at 8:29:33 PM UTC-6, Quadibloc wrote:

> Now, though, one doesn't _have_ to put the state in an elarged PSW. What Mitch
> Alsup was probably envisaging is that the preceding instruction plus at least the
> decode of the following instlruction would be *atomic* - if it can't be interrupted,
> then nothing needs to be saved.

There is, of course, an even simpler solution. Just change the definition of the
instruction so that if the length field contains zero, then, since that's absurd, that
means the instruction is variable-length, and the length is found in register zero.

I think I even saw a machine which did that, maybe for shift counts.

John Savard

In article <7fb90705-a13d-473d-8462-7b9d62e117fen@googlegroups.com>,
MitchAlsup <MitchAlsup@aol.com> wrote:
>On Thursday, July 1, 2021 at 8:39:10 PM UTC-5, Kent Dickey wrote:
>> In article <8b1baea3-a802-4341...@googlegroups.com>,
>> MitchAlsup <Mitch...@aol.com> wrote:
>> >No, it requires the JIT to run in a different address mapping than the
>> >application
>> >using the JITted code. Since this transition only costs 12 cycles plus cache
>> >effects, it is well worth while.
[snip]
>>
>> Can you explain why you're doing this? What does having the JIT modification
>> be in a different address space help in the hardware? I'm not seeing how
>> this really helps, other than to make certain JIT strategies harder.
><
>Protection::
>The executor of the code cannot modify the code (no write permission).
>The JIT is not in the address space of the "application"
>The "application" cannot modify the JITer or even see it
>The "application" can only see the ASCII code given to the JIT.
>The "application" can only execute from JIT cache.
>Thus:: JIT smells a lot more like a dynamic library than current.
>>
>> It also appears to make verification harder with out making the
>> hardware cases go away--another thread (or this thread, with a different
>> mapping) can still change code that is actively being executed, so you
>> have to handle that case still. What is your synchronization strategy?
><
>With variable length instructions it is "extremely bad" if part of the inst
>has been put in JIT cache and the rest has not. Likewise, it is bad if
>sensibly incomplete codes are put in JIT cache.
><
>JIT pauses consuming applications during JITification and restarts them
>afterwards.
><
>Also note: one can pause a number of "tasks" with a single My 66000 inst
>and likewise, those tasks can be restarted with a single inst.
>So the overhead of doing this is not what your intuition imagines.
>>
>> Kent

I thought you were saying the following:

Application A is running code at virtual address (VA) 0x5000, which maps to
physical address (PA) 0x1000. Your CPU design does not allow writes to any
page which is executable, so writes to VA 0x5000 will trap.

But Application A (same thread, maybe another thread, maybe another process
through mmap()) could create an alias so that VA=0x6000 maps to PA=0x1000,
and this does not have execute permissions so it can be writeable. So then
software can write to instructions using VA=0x6000 while they are being
executed at VA=0x5000.

If this is not possible, how is the hardware stopping it?

This is why I think you have all the hardware issues of self-modifying code
still, where you can have execution state which is inconsistent through
this virtual aliases.

Kent

On Friday, July 2, 2021 at 12:17:29 AM UTC-5, Kent Dickey wrote:
> In article <7fb90705-a13d-473d...@googlegroups.com>,
> MitchAlsup <Mitch...@aol.com> wrote:
> >On Thursday, July 1, 2021 at 8:39:10 PM UTC-5, Kent Dickey wrote:
> >> In article <8b1baea3-a802-4341...@googlegroups.com>,
> >> MitchAlsup <Mitch...@aol.com> wrote:
> >> >No, it requires the JIT to run in a different address mapping than the
> >> >application
> >> >using the JITted code. Since this transition only costs 12 cycles plus cache
> >> >effects, it is well worth while.
> [snip]
> >>
> >> Can you explain why you're doing this? What does having the JIT modification
> >> be in a different address space help in the hardware? I'm not seeing how
> >> this really helps, other than to make certain JIT strategies harder.
> ><
> >Protection::
> >The executor of the code cannot modify the code (no write permission).
> >The JIT is not in the address space of the "application"
> >The "application" cannot modify the JITer or even see it
> >The "application" can only see the ASCII code given to the JIT.
> >The "application" can only execute from JIT cache.
> >Thus:: JIT smells a lot more like a dynamic library than current.
> >>
> >> It also appears to make verification harder with out making the
> >> hardware cases go away--another thread (or this thread, with a different
> >> mapping) can still change code that is actively being executed, so you
> >> have to handle that case still. What is your synchronization strategy?
> ><
> >With variable length instructions it is "extremely bad" if part of the inst
> >has been put in JIT cache and the rest has not. Likewise, it is bad if
> >sensibly incomplete codes are put in JIT cache.
> ><
> >JIT pauses consuming applications during JITification and restarts them
> >afterwards.
> ><
> >Also note: one can pause a number of "tasks" with a single My 66000 inst
> >and likewise, those tasks can be restarted with a single inst.
> >So the overhead of doing this is not what your intuition imagines.
> >>
> >> Kent
> I thought you were saying the following:
>
> Application A is running code at virtual address (VA) 0x5000, which maps to
> physical address (PA) 0x1000. Your CPU design does not allow writes to any
> page which is executable, so writes to VA 0x5000 will trap.
>
> But Application A (same thread, maybe another thread, maybe another process
> through mmap()) could create an alias so that VA=0x6000 maps to PA=0x1000,
> and this does not have execute permissions so it can be writeable. So then
> software can write to instructions using VA=0x6000 while they are being
> executed at VA=0x5000.
>
> If this is not possible, how is the hardware stopping it?
<
All of that is possible via page mappings.
<
However I though VA[JIT] = VA[application] would work better; VA[JIT]
is writable, VA[application] is executable using different root pointers.
>
> This is why I think you have all the hardware issues of self-modifying code
> still, where you can have execution state which is inconsistent through
> this virtual aliases.
<
I simply don't want an application capable of modifying its own code.
<
>
> Kent

On Thursday, July 1, 2021 at 7:39:10 PM UTC-6, Kent Dickey wrote:

> Can you explain why you're doing this? What does having the JIT modification
> be in a different address space help in the hardware? I'm not seeing how
> this really helps, other than to make certain JIT strategies harder.

Basically, it's because in his architecture, the memory mapping system is
*the only security mechanism he's got* - there is no privileged mode, the only
way to give some processes different privilege is by giving them different memory
maps. This at least has the virtue of simplicity.

So he has to use what he has got in order to allow just-in-time compilation where
executable code is normally not modifiable; there's no other way to do it.

John Savard

MitchAlsup wrote:
> On Friday, July 2, 2021 at 12:17:29 AM UTC-5, Kent Dickey wrote:
>> In article <7fb90705-a13d-473d...@googlegroups.com>,
>> MitchAlsup <Mitch...@aol.com> wrote:
>>> On Thursday, July 1, 2021 at 8:39:10 PM UTC-5, Kent Dickey wrote:
>>>> In article <8b1baea3-a802-4341...@googlegroups.com>,
>>>> MitchAlsup <Mitch...@aol.com> wrote:
>>>>> No, it requires the JIT to run in a different address mapping than the
>>>>> application
>>>>> using the JITted code. Since this transition only costs 12 cycles plus cache
>>>>> effects, it is well worth while.
>> [snip]
>>>> Can you explain why you're doing this? What does having the JIT modification
>>>> be in a different address space help in the hardware? I'm not seeing how
>>>> this really helps, other than to make certain JIT strategies harder.
>>> <
>>> Protection::
>>> The executor of the code cannot modify the code (no write permission).
>>> The JIT is not in the address space of the "application"
>>> The "application" cannot modify the JITer or even see it
>>> The "application" can only see the ASCII code given to the JIT.
>>> The "application" can only execute from JIT cache.
>>> Thus:: JIT smells a lot more like a dynamic library than current.
>>>> It also appears to make verification harder with out making the
>>>> hardware cases go away--another thread (or this thread, with a different
>>>> mapping) can still change code that is actively being executed, so you
>>>> have to handle that case still. What is your synchronization strategy?
>>> <
>>> With variable length instructions it is "extremely bad" if part of the inst
>>> has been put in JIT cache and the rest has not. Likewise, it is bad if
>>> sensibly incomplete codes are put in JIT cache.
>>> <
>>> JIT pauses consuming applications during JITification and restarts them
>>> afterwards.
>>> <
>>> Also note: one can pause a number of "tasks" with a single My 66000 inst
>>> and likewise, those tasks can be restarted with a single inst.
>>> So the overhead of doing this is not what your intuition imagines.
>>>> Kent
>> I thought you were saying the following:
>>
>> Application A is running code at virtual address (VA) 0x5000, which maps to
>> physical address (PA) 0x1000. Your CPU design does not allow writes to any
>> page which is executable, so writes to VA 0x5000 will trap.
>>
>> But Application A (same thread, maybe another thread, maybe another process
>> through mmap()) could create an alias so that VA=0x6000 maps to PA=0x1000,
>> and this does not have execute permissions so it can be writeable. So then
>> software can write to instructions using VA=0x6000 while they are being
>> executed at VA=0x5000.
>>
>> If this is not possible, how is the hardware stopping it?
> <
> All of that is possible via page mappings.
> <
> However I though VA[JIT] = VA[application] would work better; VA[JIT]
> is writable, VA[application] is executable using different root pointers.
>> This is why I think you have all the hardware issues of self-modifying code
>> still, where you can have execution state which is inconsistent through
>> this virtual aliases.
> <
> I simply don't want an application capable of modifying its own code.
> <
>> Kent

On *nix can a thread mmap the same file into its own address space
twice at different addresses with RW and RE protections?
And would these two views be coherent, in that writes to
the RW section appear in the RE section immediately?
If both PTE's point to the same physical frame it should work,
but the question is does the OS ensure they use the same physical frame.
I tried searching but got conflicting answers.

EricP <ThatWouldBeTelling@thevillage.com> writes:
>On *nix can a thread mmap the same file into its own address space
>twice at different addresses with RW and RE protections?

I have not tried it, but I would be surprised if it did not work.

>And would these two views be coherent, in that writes to
>the RW section appear in the RE section immediately?

Yes. To my surprise, this even worked with the virtually-indexed
virtually-tagged cache of the 21064a (or was it the 21264?). I wrote
this up in a web page, but cannot find it.

- 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:
>EricP <ThatWouldBeTelling@thevillage.com> writes:
>>On *nix can a thread mmap the same file into its own address space
>>twice at different addresses with RW and RE protections?
>
>I have not tried it, but I would be surprised if it did not work.
>
>>And would these two views be coherent, in that writes to
>>the RW section appear in the RE section immediately?
>
>Yes. To my surprise, this even worked with the virtually-indexed
>virtually-tagged cache of the 21064a (or was it the 21264?). I wrote
>this up in a web page, but cannot find it.

I found it. The program is:

<http://www.complang.tuwien.ac.at/anton/toggle_dc_16k/mapcheck.c>

and I commented on that
<http://www.complang.tuwien.ac.at/anton/toggle_dc_16k/>:

|I was worried about cache consistency issues arising with the
|virtually indexed cache. Therefore I have written a test program for
|checking this. The result is that the test went well even with 16K
|D-cache. My guess is that the hardware invalidates the other cached
|instance of the same physical memory location automatically with bus
|snooping logic or somesuch.

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

On Friday, July 2, 2021 at 4:08:58 PM UTC-5, EricP wrote:
> MitchAlsup wrote:
> > On Friday, July 2, 2021 at 12:17:29 AM UTC-5, Kent Dickey wrote:
> >> In article <7fb90705-a13d-473d...@googlegroups.com>,
> >> MitchAlsup <Mitch...@aol.com> wrote:
> >>> On Thursday, July 1, 2021 at 8:39:10 PM UTC-5, Kent Dickey wrote:
> >>>> In article <8b1baea3-a802-4341...@googlegroups.com>,
> >>>> MitchAlsup <Mitch...@aol.com> wrote:
> >>>>> No, it requires the JIT to run in a different address mapping than the
> >>>>> application
> >>>>> using the JITted code. Since this transition only costs 12 cycles plus cache
> >>>>> effects, it is well worth while.
> >> [snip]
> >>>> Can you explain why you're doing this? What does having the JIT modification
> >>>> be in a different address space help in the hardware? I'm not seeing how
> >>>> this really helps, other than to make certain JIT strategies harder.
> >>> <
> >>> Protection::
> >>> The executor of the code cannot modify the code (no write permission).
> >>> The JIT is not in the address space of the "application"
> >>> The "application" cannot modify the JITer or even see it
> >>> The "application" can only see the ASCII code given to the JIT.
> >>> The "application" can only execute from JIT cache.
> >>> Thus:: JIT smells a lot more like a dynamic library than current.
> >>>> It also appears to make verification harder with out making the
> >>>> hardware cases go away--another thread (or this thread, with a different
> >>>> mapping) can still change code that is actively being executed, so you
> >>>> have to handle that case still. What is your synchronization strategy?
> >>> <
> >>> With variable length instructions it is "extremely bad" if part of the inst
> >>> has been put in JIT cache and the rest has not. Likewise, it is bad if
> >>> sensibly incomplete codes are put in JIT cache.
> >>> <
> >>> JIT pauses consuming applications during JITification and restarts them
> >>> afterwards.
> >>> <
> >>> Also note: one can pause a number of "tasks" with a single My 66000 inst
> >>> and likewise, those tasks can be restarted with a single inst.
> >>> So the overhead of doing this is not what your intuition imagines.
> >>>> Kent
> >> I thought you were saying the following:
> >>
> >> Application A is running code at virtual address (VA) 0x5000, which maps to
> >> physical address (PA) 0x1000. Your CPU design does not allow writes to any
> >> page which is executable, so writes to VA 0x5000 will trap.
> >>
> >> But Application A (same thread, maybe another thread, maybe another process
> >> through mmap()) could create an alias so that VA=0x6000 maps to PA=0x1000,
> >> and this does not have execute permissions so it can be writeable. So then
> >> software can write to instructions using VA=0x6000 while they are being
> >> executed at VA=0x5000.
> >>
> >> If this is not possible, how is the hardware stopping it?
> > <
> > All of that is possible via page mappings.
> > <
> > However I though VA[JIT] = VA[application] would work better; VA[JIT]
> > is writable, VA[application] is executable using different root pointers.
> >> This is why I think you have all the hardware issues of self-modifying code
> >> still, where you can have execution state which is inconsistent through
> >> this virtual aliases.
> > <
> > I simply don't want an application capable of modifying its own code.
> > <
> >> Kent
> On *nix can a thread mmap the same file into its own address space
> twice at different addresses with RW and RE protections?
<
Most can.
<
> And would these two views be coherent, in that writes to
> the RW section appear in the RE section immediately?
<
To data (LDs and STs) yes, to instructions, not necessarily. You see the FETCH
stage is endowed with the ability to fetch considerably in front of the LDs and
STs in the execution pipeline. So, it the ICache would get invalidated upon
data write within a few cycles, the FETCH stage could have read the old data
and not gotten around to issuing it yet.
<
You probably need some kind of Mfence which synchronizes Writes and Fetches.
<
> If both PTE's point to the same physical frame it should work,
<
What is a frame ?
<
> but the question is does the OS ensure they use the same physical frame.
> I tried searching but got conflicting answers.
<
Again, what is a frame ?

MitchAlsup wrote:
> On Friday, July 2, 2021 at 4:08:58 PM UTC-5, EricP wrote:
> <
>> If both PTE's point to the same physical frame it should work,
> <
> What is a frame ?

The name for a physical memory page. I suppose because people got
tired of saying "virtual page" "physical page" so "page" means virtual
and "frame" mean physical. Saves typing.

Unless one does what I did and says "physical frame",
in which case the whole exercise is pointless.

But isn't that just the way of the whole universe?

On Friday, July 2, 2021 at 8:34:08 PM UTC-5, EricP wrote:
> MitchAlsup wrote:
> > On Friday, July 2, 2021 at 4:08:58 PM UTC-5, EricP wrote:
> > <
> >> If both PTE's point to the same physical frame it should work,
> > <
> > What is a frame ?
> The name for a physical memory page. I suppose because people got
> tired of saying "virtual page" "physical page" so "page" means virtual
> and "frame" mean physical. Saves typing.
<
When there are Hypervisors with their own mapping it merely confuses
the situation more.
>
> Unless one does what I did and says "physical frame",
> in which case the whole exercise is pointless.
>
> But isn't that just the way of the whole universe?
<
You mean that pointless thing ????

According to Quadibloc <jsavard@ecn.ab.ca>:
>> Now, though, one doesn't _have_ to put the state in an elarged PSW. What Mitch
>> Alsup was probably envisaging is that the preceding instruction plus at least the
>> decode of the following instlruction would be *atomic* - if it can't be interrupted,
>> then nothing needs to be saved.
>
>There is, of course, an even simpler solution. Just change the definition of the
>instruction so that if the length field contains zero, then, since that's absurd, that
>means the instruction is variable-length, and the length is found in register zero.

What the 360 actually did was to make the length in the instruction one less than
the actual length so values 0-255 meant lengths 1-256. I suppose you could have reserved
a value and made it 1-255, but when processing long strings of data, handling it as
256 byte chunks was a lot more efficient than 255 byte chunks since shifting and masking
was a lot faster than dividing by 255.

As I keep pointing out, the 360 was designed in the 1960s. There were no pipelines,
no caches, and computers were built out of individual transistors. The performance
penalty for the EX target being somewhere else rather than in-line was zero.

It didn't take very long for them to realize that people wanted a
better way to handle variable length strings. In 1970, S/370 added
MVCL and CLCL instructions that took the addresses and lengths from
registers so operands could be up to the full size of the address space.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On Friday, July 2, 2021 at 8:01:51 PM UTC-6, John Levine wrote:

> As I keep pointing out, the 360 was designed in the 1960s. There were no pipelines,
> no caches, and computers were built out of individual transistors.

Competing computers were built out of individual transistors. IBM's System/360
was built out of integrated circuits.

Or at least IBM said so.

What IBM's System/360 was built from was Solid Logic Technology (SLT). Little
square silicon dies containing individual transistors were applied to a printed
circuit on an alumina insulating substrate. Then the circuit was passivated by
being coated in leaded glass (to lower the melting point) and an aluminum cap
was put over the substrate to make a module with pins on the bottom.

Because IBM sold a _lot_ of computers, having automatic machinery place individual
transistors on a multi-chip module like this was economically viable for them;
everyone else had to wait until it was reasonable to switch from discrete transistors
to *monolithic* integrated circuits.

John Savard

On Friday, July 2, 2021 at 9:01:51 PM UTC-5, John Levine wrote:
> According to Quadibloc <jsa...@ecn.ab.ca>:
> >> Now, though, one doesn't _have_ to put the state in an elarged PSW. What Mitch
> >> Alsup was probably envisaging is that the preceding instruction plus at least the
> >> decode of the following instlruction would be *atomic* - if it can't be interrupted,
> >> then nothing needs to be saved.
> >
> >There is, of course, an even simpler solution. Just change the definition of the
> >instruction so that if the length field contains zero, then, since that's absurd, that
> >means the instruction is variable-length, and the length is found in register zero.
> What the 360 actually did was to make the length in the instruction one less than
> the actual length so values 0-255 meant lengths 1-256. I suppose you could have reserved
> a value and made it 1-255, but when processing long strings of data, handling it as
> 256 byte chunks was a lot more efficient than 255 byte chunks since shifting and masking
> was a lot faster than dividing by 255.
>
> As I keep pointing out, the 360 was designed in the 1960s. There were no pipelines,
<
7090 was pipelined.............
<
> no caches, and computers were built out of individual transistors. The performance
> penalty for the EX target being somewhere else rather than in-line was zero.
>
> It didn't take very long for them to realize that people wanted a
> better way to handle variable length strings. In 1970, S/370 added
> MVCL and CLCL instructions that took the addresses and lengths from
> registers so operands could be up to the full size of the address space.
> --
> Regards,
> John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly

According to Quadibloc <jsavard@ecn.ab.ca>:
>On Friday, July 2, 2021 at 8:01:51 PM UTC-6, John Levine wrote:
>
>> As I keep pointing out, the 360 was designed in the 1960s. There were no pipelines,
>> no caches, and computers were built out of individual transistors.
>
>Competing computers were built out of individual transistors. IBM's System/360
>was built out of integrated circuits.

Nope.

>Or at least IBM said so.

Nope.

>What IBM's System/360 was built from was Solid Logic Technology (SLT). Little
>square silicon dies containing individual transistors were applied to a printed
>circuit on an alumina insulating substrate.

Right, SLT was several individual transistors mounted on a substrate
in each package. Each transistor was produced and tested separately.
IBM looked at chips with multiple transistors but at that point the
yield on individual transistors was about 50% and the yield on
multi-device chips would be impossibly low.

Their first integrated circuits were MST used in the 360/85 in December 1969
and S/3 in January 1970.

"IBM's 360 and early 370 Systems" describes this in detail in chapters 2 and 8.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

According to MitchAlsup <MitchAlsup@aol.com>:
>On Friday, July 2, 2021 at 9:01:51 PM UTC-5, John Levine wrote:
>> As I keep pointing out, the 360 was designed in the 1960s. There were no pipelines,
><
>7090 was pipelined.............

"IBM's Early Computers" says the 7090 was a reimplemented 709 using
technology from the STRETCH. While STRETCH had a lookahead feature to
try to start memory accesses early which I suppose was a kind of
pipeline, it doesn't seem to have made it into the 7090. The
instruction timings in the 7090 manual at bitsavers don't say anything
that suggests there might be pipelining.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly