On Monday, September 6, 2021 at 11:54:43 AM UTC-5, Nemo wrote:
> On 2021-09-06 09:44, Stefan Monnier wrote:
> >> I see no unsurmountable hurdles to create a JavaVM front end for an
> >> appropriate OoO machine that produces a similar utilization of the FUs
> >> of the OoO machine. Note that there is no aliasing problem wrt the
> >> locals slots on the JavaVM.
> >
> > Whether a JVM CPU is possible (and even efficient) is probably
> > a hypothetical question at this point. The main question is: where's
> > the market for it?
<
> Well, billions of UICC devices (called sim cards) would be a lucrative
> market.
<
I was doing some reading in the I/O MMU category last week and ran into
some academia papers indicating that this is a potent market for viruses.
That is, what Spectré and Meltdown did for CPUs, the same attack vectors
are being palyed out over in the plug-in device arena.
>
> Sun specified picoJava [sic] years ago but never released a product and
> it never took off. Nowadays, there is Jazelle on ARM and the Atmel
> AT90SC is fast enough so the JVM-on-silicon ship has probably sailed.
>
> N.
> >
> > Reminds me of the Lisp machines,
> >
> >
> > Stefan
> >

On 9/6/2021 12:31 PM, MitchAlsup wrote:
> On Monday, September 6, 2021 at 11:49:41 AM UTC-5, BGB wrote:
>> On 9/6/2021 8:25 AM, Anton Ertl wrote:
>>> gareth evans <headst...@yahoo.com> writes:
>>>> This seems like a recipe for viruses!
>>>
>>> This sentence *is* a recipe for security theatre.
>>>
>> Meanwhile, am I like the only person with an ISA who has stuff like (?):
>> Memory that is RWX for the kernel, but R-X or --X for usermode;
>> Memory that is RW- for the kernel, but R-- for usermode;
>> ...
> No.

OK. In any case, x86 doesn't seem able to do this.

Descriptions of ARM's MMU are a bit more fragmented and confusing, so
less obvious what it can do.

In any case, I should have specified "within a single address space,
without flushing the TLB or changing modes or similar".

>>
>>
>> This is before getting to the keyring, which can also be like:
>> VM program thread sees the memory as R-X;
>> JIT compiler thread sees the memory as RW-;
>> ...
>>
>> Though, the (more recent) addition of separate User and Supervisor
>> access is a bit limited/hacky given there weren't any free bits, so some
>> level of twiddly was used.
>>
>>
>> Likewise, say:
>> Task register (TBR) points to an area which is Read-Only from usermode,
>> but Read/Write to the kernel, pointing to another region which is
>> Read/Write from usermode (TLS variables and similar go here), and to a
>> region which is inaccessible from usermode (holds system-level state).
>>
>> ...
>>
>>
>> Granted, some of this stuff only works from usermode and with the MMU
>> enabled, where currently I only have the MME enabled if a swapfile was
>> found. This may change (with the MMU always being enabled after
>> boot-up), given I seem to now have the MMU relatively stable.
>>
>> Even without a pagefile, the MMU could still allow for things like
>> remapping pages, growable stacks, ... It would also allow for usermode
>> programs to be less subject to the issues of RAM fragmentation.
>>
>> At present, paged virtual memory is still mostly untested and fairly
>> incomplete (it also bypasses the normal filesystem code and requires the
>> swapfile to be contiguous on the SDcard). The use of a swapfile (rather
>> than a swap partition) being mostly because I didn't have a good way to
>> create such a partition via the Windows tools.
>>
>> ...

On 06.09.2021 18:12, MitchAlsup wrote:
> The stack nature of the bytecode is the most significant imposition.

There is a concept for HW OoO execution of stack-based code, called
"BOOST: Berkeley Out-of-Order Stack Thingy" (see
<http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.137.5216>; only
the cached copy at
<http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.137.5216&rep=rep1&type=pdf>
still works).

On Monday, September 6, 2021 at 1:22:05 PM UTC-5, Bernd Linsel wrote:
> On 06.09.2021 18:12, MitchAlsup wrote:
> > The stack nature of the bytecode is the most significant imposition.
> There is a concept for HW OoO execution of stack-based code, called
> "BOOST: Berkeley Out-of-Order Stack Thingy" (see
> <http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.137.5216>; only
> the cached copy at
> <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.137.5216&rep=rep1&type=pdf>
> still works).
<
Same problems as::
https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.74.7112&rep=rep1&type=pdf
<

On Monday, September 6, 2021 at 12:44:19 PM UTC-5, BGB wrote:
> On 9/6/2021 12:31 PM, MitchAlsup wrote:
> > On Monday, September 6, 2021 at 11:49:41 AM UTC-5, BGB wrote:
> >> On 9/6/2021 8:25 AM, Anton Ertl wrote:
> >>> gareth evans <headst...@yahoo.com> writes:
> >>>> This seems like a recipe for viruses!
> >>>
> >>> This sentence *is* a recipe for security theatre.
> >>>
> >> Meanwhile, am I like the only person with an ISA who has stuff like (?):
> >> Memory that is RWX for the kernel, but R-X or --X for usermode;
> >> Memory that is RW- for the kernel, but R-- for usermode;
> >> ...
> > No.
> OK. In any case, x86 doesn't seem able to do this.
>
> Descriptions of ARM's MMU are a bit more fragmented and confusing, so
> less obvious what it can do.
>
> In any case, I should have specified "within a single address space,
> without flushing the TLB or changing modes or similar".
>
In My 66000, the MMU is defined such that that the Root <pointer> and
all intermediate PTPs have to allow an access mode for the mode to be
"granted". Thus one Root may allow RW- and another root allow --X and
the page tables can still be shared.
<
So, k different processes can share a subsection of the virtual address
space and have different rights to it. One Root (say the JIT) is given
RW- access to the compiled Java, the others are given --X access, The
entire set of tables is shared.
<
In effect, I synthesize an ASID through the Root and all the PTPs
leading to the PTE. So any sharing of address spaces results in sharing
(and avoidance of invalidating) TLB entries.

Bernd Linsel <bl1-removethis@gmx.com> schrieb:
> On 06.09.2021 18:12, MitchAlsup wrote:
>> The stack nature of the bytecode is the most significant imposition.
>
> There is a concept for HW OoO execution of stack-based code, called
> "BOOST: Berkeley Out-of-Order Stack Thingy" (see
><http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.137.5216>; only
> the cached copy at
><http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.137.5216&rep=rep1&type=pdf>
> still works).

I love that footnote:

"Since most compiler generate stack-based code for languages such
as C with re-entrant functions, most GPR machines wind up emulating
stack machines to a significant extent."

On Monday, September 6, 2021 at 2:03:00 PM UTC-5, Thomas Koenig wrote:
> Bernd Linsel <bl1-rem...@gmx.com> schrieb:
> > On 06.09.2021 18:12, MitchAlsup wrote:
> >> The stack nature of the bytecode is the most significant imposition.
> >
> > There is a concept for HW OoO execution of stack-based code, called
> > "BOOST: Berkeley Out-of-Order Stack Thingy" (see
> ><http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.137.5216>; only
> > the cached copy at
> ><http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.137.5216&rep=rep1&type=pdf>
> > still works).
> I love that footnote:
>
> "Since most compiler generate stack-based code for languages such
> as C with re-entrant functions, most GPR machines wind up emulating
> stack machines to a significant extent."
<
Errrrrr, not really.........

EricP wrote:
> Thomas Koenig wrote:
>> MitchAlsup <MitchAlsup@aol.com> schrieb:
>>> On Sunday, September 5, 2021 at 5:05:33 PM UTC-5, Thomas Koenig wrote:
>>>> Although there are Java bytecode processors (even one available on
>>>> Github, https://github.com/amal029/jop) they have had very limited
>>>> success.
>>>> Why?
>>> <
>>> A Bytecode interpreter, even in HW will have a serious performance
>>> issue when compared to a cross compiling native instruction set.
>>> Probably around 2×-3× penalty.
>>
>> Of course, the latency of the first-time compilation is somewhat
>> large :-)
>>
>> It is interesting to read the claims about picojava, which are
>> (unfortunately) not substantiated anywhere where I can get
>> to without a paywall.
>
> 1997 paper by Sun engineers on picoJava uArch and benchmarks says
> it was 15-20 times faster than a 486/33 running interpreter,
> and about 7-10 times faster than JIT.
>
> picoJava-I: The Java Virtual Machine in Hardware, 1997
> https://tsunami.zaibatsutel.net/liberez/picojava.pdf

I remember that one, also that I was pretty much certain their
comparison with a 486-33 was completely bogus (Pentium arrived in
1993/94, then we got the PPro around 96/97?). I.e. a Pentium in the
100-200 MHz range ran 5-10 times faster than their reference 486-33.

I also remember thinking that their JVM interpreter must have been quite
bad, it should be possible to at the very least get down to less than 10
cycles (including branch misses) per JVM byte code executed, while a JIT
would run significantly faster unless you included the JIT time in the
comparison.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

On 9/6/2021 2:02 PM, Thomas Koenig wrote:
> Bernd Linsel <bl1-removethis@gmx.com> schrieb:
>> On 06.09.2021 18:12, MitchAlsup wrote:
>>> The stack nature of the bytecode is the most significant imposition.
>>
>> There is a concept for HW OoO execution of stack-based code, called
>> "BOOST: Berkeley Out-of-Order Stack Thingy" (see
>> <http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.137.5216>; only
>> the cached copy at
>> <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.137.5216&rep=rep1&type=pdf>
>> still works).
>
> I love that footnote:
>
> "Since most compiler generate stack-based code for languages such
> as C with re-entrant functions, most GPR machines wind up emulating
> stack machines to a significant extent."
>

Even when the IR is stack based, once converted to 3AC one typically
ends up with ~ 1/2 to 1/3 as many operations.

Variable load/store ops get folded into the operators.
Constants typically get folded into the operators.
Operations to duplicate or exchange stack items essentially disappear.
....

Some of the operations, rather than actually "doing something", serving
mostly to move around references to variables on an abstract "stack"
which disappears once the bytecode is decoded.

So, it can be reasonably effective as a compiler IR, but relatively poor
as something intended for direct execution or interpretation.

And, for a direct interpreter, it would likely be better to have an
instruction format more like, say:
(31:24): Source B / Imm8 / Imm16 (Hi)
(23:16): Source A / Imm16 (Lo)
(15: 8): Dest
( 7: 0): Opcode
....

But, direct interpreters have the problem that, while fairly simple and
compact, decoding and dispatching instructions tends to become a bottleneck.

It can also be noted that even in my own script VMs, while I had mostly
ended up sticking with stack-based bytecode formats, they were usually
translated (via a process similar to that mentioned previously) into a
3AC threaded-code representation (usually roughly a similar
representation at execution time to that used by my emulators).

So, the interpreter would mostly spin in a trampoline loop calling into
pre-decoded "instruction traces" rather than decode the stack bytecode
every time something was run. To some extent, type-specialization was
also done at the decoding stage, so for "auto" types, one might have
only a single version of the bytecode function, but it might split off
into multiple sets of "traces" based on the types it was called with, ...

According to Thomas Koenig <tkoenig@netcologne.de>:
>I love that footnote:
>
>"Since most compiler generate stack-based code for languages such
>as C with re-entrant functions, most GPR machines wind up emulating
>stack machines to a significant extent."

There was a time when that was true. Back in the 1970s the Unix C
compiler generated a stack intermediate code and used Sethi-Ullman
numbering to arrange the sequence of operations in an expression
to try and make it fit into the registers, or equivalently into a
fixed size stack.

But that time was long gone by the time that paper was published,
although I suppose perhaps the news had not yet arrived at Berkeley.
The Berkeley RISC was designed to run code generated by pcc, a
descendant of that Unix compiler. It did the same lousy register
allocation so they invented register windows to speed up register save
and restore.

At the same time the IBM 801 project designed a machine with an
ordinary register file programmed by the PL.8 compiler which used
graph coloring to do really good register allocation. The 801 didn't
even have load or store multiple instructions, although its
descendants added them back in. By the time that paper was published
around 2000 graph coloring had become a standard technique.

This doesn't have all that much to do with Java other than to note
that we know a lot about generating good code now and in any application
where the same routine is run more than a few times, translating it
into conventional machine code that runs fast on a conventional chip is
likely to beat anything special purpose.

--
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

John Levine <johnl@taugh.com> schrieb:
> According to Thomas Koenig <tkoenig@netcologne.de>:
>>I love that footnote:
>>
>>"Since most compiler generate stack-based code for languages such
>>as C with re-entrant functions, most GPR machines wind up emulating
>>stack machines to a significant extent."
>
> There was a time when that was true. Back in the 1970s the Unix C
> compiler generated a stack intermediate code and used Sethi-Ullman
> numbering to arrange the sequence of operations in an expression
> to try and make it fit into the registers, or equivalently into a
> fixed size stack.
>
> But that time was long gone by the time that paper was published,
> although I suppose perhaps the news had not yet arrived at Berkeley.

[...]

The paper was published in 2005, so I stronlgy suspect they knew.

However, I didn't take that remark at face value, I thoght it was
a bit tounge-in-cheek. The authors are correct in that almost all
modern compilers use stacks (zOS standard calling sequence being
an exception because of historical baggage).

John Levine <johnl@taugh.com> writes:
>According to Thomas Koenig <tkoenig@netcologne.de>:
>>I love that footnote:
>>
>>"Since most compiler generate stack-based code for languages such
>>as C with re-entrant functions, most GPR machines wind up emulating
>>stack machines to a significant extent."
>
>There was a time when that was true. Back in the 1970s the Unix C
>compiler generated a stack intermediate code and used Sethi-Ullman
>numbering to arrange the sequence of operations in an expression
>to try and make it fit into the registers, or equivalently into a
>fixed size stack.
>
>But that time was long gone by the time that paper was published,
>although I suppose perhaps the news had not yet arrived at Berkeley.
>The Berkeley RISC was designed to run code generated by pcc, a
>descendant of that Unix compiler. It did the same lousy register
>allocation so they invented register windows to speed up register save
>and restore.

The Stanford MIPS project was more compiler-oriented, and Fred Chow
used a stack-based IR called ucode for it. AFAIK this one survived
quite a long time into commercial MIPS.

>At the same time the IBM 801 project designed a machine with an
>ordinary register file programmed by the PL.8 compiler which used
>graph coloring to do really good register allocation.

In the early years of graph coloring, it was applied only at live
ranges surviving across basic block boundaries ("global register
allocation"), while "local register allocation" techniques were used
within basic blocks, probably because applying graph colouring for all
live ranges increases memory usage and compile time. A stack-based IR
for an Algol-family language typically does not keep any values on the
stack at basic-block boundaries, so there is little, if any
interaction between using a stack-based IR and global-only graph
coloring.

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

On 2021-09-06 12:25, MitchAlsup wrote (in part):
[...]
> Java byte code is stack based, to JVM would have to execute 3-4 byte
> code instructions per cycle to be in the same ball park as a GBOoO
> machine executing 1 instruction per cycle. JIT is the better path.

Are there any JIT implementations on things such as JavaCard or any UICC?

N.

Terje Mathisen wrote:
> EricP wrote:
>> Thomas Koenig wrote:
>>> MitchAlsup <MitchAlsup@aol.com> schrieb:
>>>> On Sunday, September 5, 2021 at 5:05:33 PM UTC-5, Thomas Koenig wrote:
>>>>> Although there are Java bytecode processors (even one available on
>>>>> Github, https://github.com/amal029/jop) they have had very limited
>>>>> success.
>>>>> Why?
>>>> <
>>>> A Bytecode interpreter, even in HW will have a serious performance
>>>> issue when compared to a cross compiling native instruction set.
>>>> Probably around 2×-3× penalty.
>>>
>>> Of course, the latency of the first-time compilation is somewhat
>>> large :-)
>>>
>>> It is interesting to read the claims about picojava, which are
>>> (unfortunately) not substantiated anywhere where I can get
>>> to without a paywall.
>>
>> 1997 paper by Sun engineers on picoJava uArch and benchmarks says
>> it was 15-20 times faster than a 486/33 running interpreter,
>> and about 7-10 times faster than JIT.
>>
>> picoJava-I: The Java Virtual Machine in Hardware, 1997
>> https://tsunami.zaibatsutel.net/liberez/picojava.pdf
>
> I remember that one, also that I was pretty much certain their
> comparison with a 486-33 was completely bogus (Pentium arrived in
> 1993/94, then we got the PPro around 96/97?). I.e. a Pentium in the
> 100-200 MHz range ran 5-10 times faster than their reference 486-33.

I had the same thought while reading it but had no basis
to call B.S. on the numbers.

Just from their description of how limited their microarchitecture was,
the 486 should have beat it, let alone a dual pipeline Pentium.

> I also remember thinking that their JVM interpreter must have been quite
> bad, it should be possible to at the very least get down to less than 10
> cycles (including branch misses) per JVM byte code executed, while a JIT
> would run significantly faster unless you included the JIT time in the
> comparison.
>
> Terje
>

They don't provide enough information to drill down into their
numbers and see where they are spending the x86 instructions.

Here is the Sun patent for a similar sounding contemporaneous Java cpu.
This English version was from Japan - in days of yore companies would
try to hide patents from competitors by filing in other countries,
even splitting them up across multiple countries.
With Google Patent that doesn't work any more,
found this by searching on the paper authors' name.

Instruction folding for stack-based machine, 1996
https://patents.google.com/patent/JP2006216069A/en

On 2021-09-06 00:05, Thomas Koenig wrote:
> Although there are Java bytecode processors (even one available on
> Github, https://github.com/amal029/jop) they have had very limited
> success.
>
> Why? A lot of commercial code runs on JVM now (I've heard quipped
> that Java is the new COBOL), and I would expect significant
> performance increase from a native implementation as opposed to
> an interpreter or a JIT compiler. Or have JIT compilers become
> so good that it no longer matters, and the effort of introducing
> a new architecture would be too large (again)?
>

I guess one reason is that the systems that run Java bytecode typically
also has to run other code (e.g. a Linux based OS), so you would have to
have HW support for both the Java code and something else (e.g. ARM or
x86).

Thus the Java bytecode processor would either have to be implemented as
a separate co-processor (SoC style), or as a translation layer in the
main CPU front-end.

The co-processor approach would effectively require an extra dedicated
core that can only run Java code, while the "main" core can only run
"native" (non-Java) code. This kind of heterogeneous system is very
likely to see underutilized cores, compared to just running on-demand
JIT on any core I think that this, by it self, will disqualify this
solution for most applications.

The multi-ISA front end approach has been used in many designs (x86,
ARM, etc) for similar ISA:s (e.g. THUMB+ARM32 or ARM32+ARM64), but in
those cases the ISA:s have been similar enough that the internal
architecture maps well to the different front end ISA:s. I guess that
the JVM bytecode ISA is a poor match for most modern architectures, so
it is probably difficult to create an efficient & small enough
translation front end that can co-exist with a more regular register
based ISA front end and map onto the same internal architecture.

I believe the Jazelle DBX falls into the latter category, but OTOH it
seems that it was never able to clearly beat JIT, so the extra hardware
cost probably failed to deliver any significant value in terms of
performance.

/Marcus

Thomas Koenig <tkoenig@netcologne.de> wrote:
> Although there are Java bytecode processors (even one available on
> Github, https://github.com/amal029/jop) they have had very limited
> success.
>
> Why? A lot of commercial code runs on JVM now (I've heard quipped
> that Java is the new COBOL), and I would expect significant
> performance increase from a native implementation as opposed to
> an interpreter or a JIT compiler. Or have JIT compilers become
> so good that it no longer matters, and the effort of introducing
> a new architecture would be too large (again)?

I agree with other folks that hardware bytecode is unlikely
to give better speed than JIT. For me main motivation
of bytecode is possible size optimization. I expect bytecode
to be much smaller than native code (some sources claim factor
of 6). So, keeping "cold" code in bytecode form could offer
significant space saving. OTOH executing bytecode by hardware
should be much faster than interpreter. So split between
JIT/native code and bytecode would be less critical and
larger part of application could be kept in bytecode form.

But chip designer have many ways to improve performance, it
is not clear if hardware support for bytecodes is better than
alternatives.

--
Waldek Hebisch

BGB <cr88192@gmail.com> wrote:
> On 9/5/2021 6:05 PM, MitchAlsup wrote:
>> On Sunday, September 5, 2021 at 5:05:33 PM UTC-5, Thomas Koenig wrote:
>>> Although there are Java bytecode processors (even one available on
>>> Github, https://github.com/amal029/jop) they have had very limited
>>> success.
>>>
>>> Why?
>> <
>> A Bytecode interpreter, even in HW will have a serious performance
>> issue when compared to a cross compiling native instruction set.
>> Probably around 2?-3? penalty.
>
> I think there is a reason why stack-oriented ISAs are no longer a thing.
>
> Either the stack would need to map to registers, or be treated as a
> special sort of special-purpose cache. The stack is also likely to
> become a serious bottleneck if one can't schedule multiple
> stack-operations per clock-cycle, and one would need to either operate
> at a somewhat higher clock-speed or execute a large number of
> instructions per cycle to be performance competitive with a 3R ISA.

Why would that be a problem? If you had a GBOOO machine, the stack
slots would be renamed to physical registers, just as they usually
are. In the JVM the expression stack is not of arbitrary size, but
each method context has a fixed-size array of registers. Renaming
those surely wouldn't be hard at all, as long as the stack wasn't very
large.

Andrew.

On Friday, September 10, 2021 at 8:43:39 AM UTC-5, a...@littlepinkcloud.invalid wrote:
> BGB <cr8...@gmail.com> wrote:
> > On 9/5/2021 6:05 PM, MitchAlsup wrote:
> >> On Sunday, September 5, 2021 at 5:05:33 PM UTC-5, Thomas Koenig wrote:
> >>> Although there are Java bytecode processors (even one available on
> >>> Github, https://github.com/amal029/jop) they have had very limited
> >>> success.
> >>>
> >>> Why?
> >> <
> >> A Bytecode interpreter, even in HW will have a serious performance
> >> issue when compared to a cross compiling native instruction set.
> >> Probably around 2?-3? penalty.
> >
> > I think there is a reason why stack-oriented ISAs are no longer a thing.
> >
> > Either the stack would need to map to registers, or be treated as a
> > special sort of special-purpose cache. The stack is also likely to
> > become a serious bottleneck if one can't schedule multiple
> > stack-operations per clock-cycle, and one would need to either operate
> > at a somewhat higher clock-speed or execute a large number of
> > instructions per cycle to be performance competitive with a 3R ISA.
>
> Why would that be a problem? If you had a GBOOO machine, the stack
> slots would be renamed to physical registers, just as they usually
> are. In the JVM the expression stack is not of arbitrary size, but
> each method context has a fixed-size array of registers. Renaming
> those surely wouldn't be hard at all, as long as the stack wasn't very
> large.
<
The problem comes at decode, in order to get 3-4 RISC instructions/cycle
of useful throughput, one would have to be decoding 8-10 JBC instructions
per cycle. Not saying it cannot be done, but the semantic density of the
byte is not as great as the semantic density of a RISC Word.
<
>
> Andrew.

MitchAlsup <MitchAlsup@aol.com> schrieb:
> On Friday, September 10, 2021 at 8:43:39 AM UTC-5, a...@littlepinkcloud.invalid wrote:
>> BGB <cr8...@gmail.com> wrote:
>> > On 9/5/2021 6:05 PM, MitchAlsup wrote:
>> >> On Sunday, September 5, 2021 at 5:05:33 PM UTC-5, Thomas Koenig wrote:
>> >>> Although there are Java bytecode processors (even one available on
>> >>> Github, https://github.com/amal029/jop) they have had very limited
>> >>> success.
>> >>>
>> >>> Why?
>> >> <
>> >> A Bytecode interpreter, even in HW will have a serious performance
>> >> issue when compared to a cross compiling native instruction set.
>> >> Probably around 2?-3? penalty.
>> >
>> > I think there is a reason why stack-oriented ISAs are no longer a thing.
>> >
>> > Either the stack would need to map to registers, or be treated as a
>> > special sort of special-purpose cache. The stack is also likely to
>> > become a serious bottleneck if one can't schedule multiple
>> > stack-operations per clock-cycle, and one would need to either operate
>> > at a somewhat higher clock-speed or execute a large number of
>> > instructions per cycle to be performance competitive with a 3R ISA.
>>
>> Why would that be a problem? If you had a GBOOO machine, the stack
>> slots would be renamed to physical registers, just as they usually
>> are. In the JVM the expression stack is not of arbitrary size, but
>> each method context has a fixed-size array of registers. Renaming
>> those surely wouldn't be hard at all, as long as the stack wasn't very
>> large.
><
> The problem comes at decode, in order to get 3-4 RISC instructions/cycle
> of useful throughput, one would have to be decoding 8-10 JBC instructions
> per cycle. Not saying it cannot be done, but the semantic density of the
> byte is not as great as the semantic density of a RISC Word.

Also, it is apparently beneficial to elide some pure stack movement
instructions at decode time (which was in one of the publications).

Still, if you have ~2 single-byte stack instructions for a 32-bit
RISC instruction, at least the icache can be smaller.

On Friday, September 10, 2021 at 3:42:58 PM UTC-5, Thomas Koenig wrote:
> MitchAlsup <Mitch...@aol.com> schrieb:
> > On Friday, September 10, 2021 at 8:43:39 AM UTC-5, a...@littlepinkcloud.invalid wrote:
> >> BGB <cr8...@gmail.com> wrote:
> >> > On 9/5/2021 6:05 PM, MitchAlsup wrote:
> >> >> On Sunday, September 5, 2021 at 5:05:33 PM UTC-5, Thomas Koenig wrote:
> >> >>> Although there are Java bytecode processors (even one available on
> >> >>> Github, https://github.com/amal029/jop) they have had very limited
> >> >>> success.
> >> >>>
> >> >>> Why?
> >> >> <
> >> >> A Bytecode interpreter, even in HW will have a serious performance
> >> >> issue when compared to a cross compiling native instruction set.
> >> >> Probably around 2?-3? penalty.
> >> >
> >> > I think there is a reason why stack-oriented ISAs are no longer a thing.
> >> >
> >> > Either the stack would need to map to registers, or be treated as a
> >> > special sort of special-purpose cache. The stack is also likely to
> >> > become a serious bottleneck if one can't schedule multiple
> >> > stack-operations per clock-cycle, and one would need to either operate
> >> > at a somewhat higher clock-speed or execute a large number of
> >> > instructions per cycle to be performance competitive with a 3R ISA.
> >>
> >> Why would that be a problem? If you had a GBOOO machine, the stack
> >> slots would be renamed to physical registers, just as they usually
> >> are. In the JVM the expression stack is not of arbitrary size, but
> >> each method context has a fixed-size array of registers. Renaming
> >> those surely wouldn't be hard at all, as long as the stack wasn't very
> >> large.
> ><
> > The problem comes at decode, in order to get 3-4 RISC instructions/cycle
> > of useful throughput, one would have to be decoding 8-10 JBC instructions
> > per cycle. Not saying it cannot be done, but the semantic density of the
> > byte is not as great as the semantic density of a RISC Word.
<
> Also, it is apparently beneficial to elide some pure stack movement
> instructions at decode time (which was in one of the publications).
<
Elision is something HW has a definite horizon for which SW does not.
>
> Still, if you have ~2 single-byte stack instructions for a 32-bit
> RISC instruction, at least the icache can be smaller.
<
Or higher performing.....

On 9/10/2021 8:43 AM, aph@littlepinkcloud.invalid wrote:
> BGB <cr88192@gmail.com> wrote:
>> On 9/5/2021 6:05 PM, MitchAlsup wrote:
>>> On Sunday, September 5, 2021 at 5:05:33 PM UTC-5, Thomas Koenig wrote:
>>>> Although there are Java bytecode processors (even one available on
>>>> Github, https://github.com/amal029/jop) they have had very limited
>>>> success.
>>>>
>>>> Why?
>>> <
>>> A Bytecode interpreter, even in HW will have a serious performance
>>> issue when compared to a cross compiling native instruction set.
>>> Probably around 2?-3? penalty.
>>
>> I think there is a reason why stack-oriented ISAs are no longer a thing.
>>
>> Either the stack would need to map to registers, or be treated as a
>> special sort of special-purpose cache. The stack is also likely to
>> become a serious bottleneck if one can't schedule multiple
>> stack-operations per clock-cycle, and one would need to either operate
>> at a somewhat higher clock-speed or execute a large number of
>> instructions per cycle to be performance competitive with a 3R ISA.
>
> Why would that be a problem? If you had a GBOOO machine, the stack
> slots would be renamed to physical registers, just as they usually
> are. In the JVM the expression stack is not of arbitrary size, but
> each method context has a fixed-size array of registers. Renaming
> those surely wouldn't be hard at all, as long as the stack wasn't very
> large.
>

On most machines where this sort of thing is tempting, they have
typically been using small in-order processors.

Needing to use register renaming and possibly skipping over a variable
numbers of instructions during decode seems like a bit of a stretch.

Then again, thinking about it, "just taking the hit" could still be
better than a plain interpreter on a machine which is too small to be
able to run a JIT. But, then I guess the question is more what sorts of
machines are too small to afford a JIT, but still big enough to where
running a JVM makes sense.

A JIT, unlike a full compiler, does not particularly need to be
particularly complicated or memory intensive (more so when the bytecode
ops have already sorted out things like value types, etc).

Many of the remaining complicated/expensive parts (such as the logic to
deal with in-memory object layouts, ...) would have already been needed
by the interpreter.

....

On Tuesday, September 7, 2021 at 9:45:02 AM UTC-5, anti...@math.uni.wroc.pl wrote:
> Thomas Koenig <tko...@netcologne.de> wrote:
> > Although there are Java bytecode processors (even one available on
> > Github, https://github.com/amal029/jop) they have had very limited
> > success.
> >
> > Why? A lot of commercial code runs on JVM now (I've heard quipped
> > that Java is the new COBOL), and I would expect significant
> > performance increase from a native implementation as opposed to
> > an interpreter or a JIT compiler. Or have JIT compilers become
> > so good that it no longer matters, and the effort of introducing
> > a new architecture would be too large (again)?
> I agree with other folks that hardware bytecode is unlikely
> to give better speed than JIT. For me main motivation
> of bytecode is possible size optimization. I expect bytecode
> to be much smaller than native code (some sources claim factor
> of 6). So, keeping "cold" code in bytecode form could offer
> significant space saving. OTOH executing bytecode by hardware
> should be much faster than interpreter. So split between
> JIT/native code and bytecode would be less critical and
> larger part of application could be kept in bytecode form.
>
> But chip designer have many ways to improve performance, it
> is not clear if hardware support for bytecodes is better than
> alternatives.
>
> --
> Waldek Hebisch

Explore extending a byte code ISA to a two byte ISA.
gives both a stack operator and a stack reference
and with the few remaining bits one can concoct all manner
of extras: replace result into stack reference, pop/push the stack,
indirect addressing through the stack reference, apply indexing
to the stack reference as an address
I.e. use the stack frame of mind/reference to add features which
map into RISC instructions easily.

The goal is to decrease the instruction count and increase the semantic content.
What results may cross the boundaries between all the architectural norms?
Could go into more detail except prefer others work the problem for a while?

On 9/10/2021 3:42 PM, Thomas Koenig wrote:
> MitchAlsup <MitchAlsup@aol.com> schrieb:
>> On Friday, September 10, 2021 at 8:43:39 AM UTC-5, a...@littlepinkcloud.invalid wrote:
>>> BGB <cr8...@gmail.com> wrote:
>>>> On 9/5/2021 6:05 PM, MitchAlsup wrote:
>>>>> On Sunday, September 5, 2021 at 5:05:33 PM UTC-5, Thomas Koenig wrote:
>>>>>> Although there are Java bytecode processors (even one available on
>>>>>> Github, https://github.com/amal029/jop) they have had very limited
>>>>>> success.
>>>>>>
>>>>>> Why?
>>>>> <
>>>>> A Bytecode interpreter, even in HW will have a serious performance
>>>>> issue when compared to a cross compiling native instruction set.
>>>>> Probably around 2?-3? penalty.
>>>>
>>>> I think there is a reason why stack-oriented ISAs are no longer a thing.
>>>>
>>>> Either the stack would need to map to registers, or be treated as a
>>>> special sort of special-purpose cache. The stack is also likely to
>>>> become a serious bottleneck if one can't schedule multiple
>>>> stack-operations per clock-cycle, and one would need to either operate
>>>> at a somewhat higher clock-speed or execute a large number of
>>>> instructions per cycle to be performance competitive with a 3R ISA.
>>>
>>> Why would that be a problem? If you had a GBOOO machine, the stack
>>> slots would be renamed to physical registers, just as they usually
>>> are. In the JVM the expression stack is not of arbitrary size, but
>>> each method context has a fixed-size array of registers. Renaming
>>> those surely wouldn't be hard at all, as long as the stack wasn't very
>>> large.
>> <
>> The problem comes at decode, in order to get 3-4 RISC instructions/cycle
>> of useful throughput, one would have to be decoding 8-10 JBC instructions
>> per cycle. Not saying it cannot be done, but the semantic density of the
>> byte is not as great as the semantic density of a RISC Word.
>
> Also, it is apparently beneficial to elide some pure stack movement
> instructions at decode time (which was in one of the publications).
>
> Still, if you have ~2 single-byte stack instructions for a 32-bit
> RISC instruction, at least the icache can be smaller.
>

One can get a similar savings by also having 16-bit instructions.

An ISA with a mix of 16 and 32 bit encodings can do pretty good on a
code-density front.

Meanwhile, the number of 16-bit ops needed is still less than it would
require to do an operation with stack ops.

Though, I can note a possibly related bit of trivia:
My C compiler uses a stack-based IR (RIL3), which is along vaguely
similar lines to JVM and .NET bytecode;
The RIL bytecode for the C library tends to actually be several times
larger than the typical size of the final binaries.

Granted, the RIL bytecode has a few drawbacks here:
Contains a lot of symbolic information (function and variable names);
May contain code or functions which are culled from the final binary;
Other format quirks, such as the format using bytecode ops to also
encode most of the metadata;
....

As with .NET bytecode, most RIL ops do not encode types, but rather
receive the types via the stack.

No current plans though for a RIL interpreter for BJX2, but the design
isn't really a great format for an interpreter.

Would ideally want a format with explicitly typed bytecode ops and
structure-based metadata, more like either JVM bytecode or my prior
BS2VM bytecode (which was itself sort of like JVM bytecode, just with a
single large "bytecode image file" in place of a bunch of ".class"
files; and with an expanded type-system and assumed the use of 64-bit
stack elements), but expanded out to be effectively usable as a target
for compiling C and similar.

....

On Friday, September 10, 2021 at 5:13:36 PM UTC-5, JimBrakefield wrote:
> On Tuesday, September 7, 2021 at 9:45:02 AM UTC-5, anti...@math.uni.wroc.pl wrote:
> > Thomas Koenig <tko...@netcologne.de> wrote:
> > > Although there are Java bytecode processors (even one available on
> > > Github, https://github.com/amal029/jop) they have had very limited
> > > success.
> > >
> > > Why? A lot of commercial code runs on JVM now (I've heard quipped
> > > that Java is the new COBOL), and I would expect significant
> > > performance increase from a native implementation as opposed to
> > > an interpreter or a JIT compiler. Or have JIT compilers become
> > > so good that it no longer matters, and the effort of introducing
> > > a new architecture would be too large (again)?
> > I agree with other folks that hardware bytecode is unlikely
> > to give better speed than JIT. For me main motivation
> > of bytecode is possible size optimization. I expect bytecode
> > to be much smaller than native code (some sources claim factor
> > of 6). So, keeping "cold" code in bytecode form could offer
> > significant space saving. OTOH executing bytecode by hardware
> > should be much faster than interpreter. So split between
> > JIT/native code and bytecode would be less critical and
> > larger part of application could be kept in bytecode form.
> >
> > But chip designer have many ways to improve performance, it
> > is not clear if hardware support for bytecodes is better than
> > alternatives.
> >
> > --
> > Waldek Hebisch
> Explore extending a byte code ISA to a two byte ISA.
> gives both a stack operator and a stack reference
> and with the few remaining bits one can concoct all manner
> of extras: replace result into stack reference, pop/push the stack,
> indirect addressing through the stack reference, apply indexing
> to the stack reference as an address
> I.e. use the stack frame of mind/reference to add features which
> map into RISC instructions easily.
>
> The goal is to decrease the instruction count and increase the semantic content.
> What results may cross the boundaries between all the architectural norms?
> Could go into more detail except prefer others work the problem for a while?

Duh, mistook the discussion thread to be about possible/potential byte code
hardware implementations rather than official Java byte code hardware implementation.
E.g I'm interested in potential Java hardware targets rather than official Java byte code
hardware processing. Didn't see the tree for the forest?

Still there is the question of the best JIT byte code target?

According to JimBrakefield <jim.brakefield@ieee.org>:
>Explore extending a byte code ISA to a two byte ISA.
>gives both a stack operator and a stack reference
>and with the few remaining bits one can concoct all manner
>of extras: replace result into stack reference, pop/push the stack,
>indirect addressing through the stack reference, apply indexing
>to the stack reference as an address
> I.e. use the stack frame of mind/reference to add features which
>map into RISC instructions easily.

Sounds a lot like a PDP-11.

--
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