On Mon, 22 Oct 2007 21:59:21 -0500, rpw3@rpw3.org (Rob Warnock) wrote:

> Nick Maclaren <nmm1@cus.cam.ac.uk> wrote:
<snip>
> Don't forget, DEC did it *both* ways! The PDP-10's hardware stack
> grew "up"; the PDP-11's grew "down". The overlap in the lifecycle
> of those two product lines was quite considerable. In fact, many
> later PDP-10s used PDP-11s as front-end processors, so you even had
> both ways in one system!  ;-}
> 
Nit: 1s/stack$/&s/
On -10 for (explicit) call/return and/or data you could have one stack
for each GPR you were able to dedicate; none was used for interrupts
etc. and thus could be considered a hardware preference/definition,
the way R6=SP (or specifically KSP) is on -11.

- formerly david.thompson1 || achar(64) || worldnet.att.net

Jules wrote:
(snip)

> FWIW, this is a misleading, if not actually incorrect statement.  The
> Java virtual machine is endian-independent, in that the architecture
> is defined such that an implementation may use any byte order, and it
> is impossible for a program running on it to determine which is in
> use.  Software implementations typically use the endianness of their
> underlying hardware.  Hardware implementations seem to normally be big-
> endian, but there is no reason this is necessary.

> Java's I/O libraries are defined to use big-endian order, but this is
> a library issue, not an architectural one.

As visible to the user, it is big-endian.  If you consider
JVM as a processor architecture intended to run JVM code
and Java libraries it is reasonable to call it big-endian.

Many processors now are bi-endian, but internally they choose
one or the other with conversion done on load/store operations.
Alpha, can even load/store VAX middle-endian floating point data.

In general, one doesn't define endianness where it isn't visible
to the user in any way (for example, on internal processor registers).
Externally, JVM looks big-endian.

-- glen

On Oct 31, 1:20 am, Jules <ju...@dsf.org.uk> wrote:
> On Oct 23, 11:06 am, karthikbalaguru <karthikbalagur...@gmail.com>
> wrote:
>
> >http://www.intel.com/design/intarch/papers/endian.pdf->
> > Refer the section "Merits of Endian Architectures" and the Table for
> > clarifications w.r.t endiannes
>
> [...]
> > Java Virtual Machine*                   - Big-Endian
>
> FWIW, this is a misleading, if not actually incorrect statement.  The
> Java virtual machine is endian-independent, in that the architecture
> is defined such that an implementation may use any byte order, and it
> is impossible for a program running on it to determine which is in
> use.  Software implementations typically use the endianness of their
> underlying hardware.  Hardware implementations seem to normally be big-
> endian, but there is no reason this is necessary.
>
> Java's I/O libraries are defined to use big-endian order, but this is
> a library issue, not an architectural one.
>
> </jvm-implementor-pedanticism>

But, i got another link that states the same info.

http://www.netrino.com/Publications/Glossary/Endianness.php -> This
link
also states that "The Java Virtual Machine is big endian as well."

Is there any modified version of 'Java Virtual Machine' that is
independent of endianness ?

Can you share some link in the internet that discusses more about
this.

Karthik Balaguru

On Oct 23, 11:06 am, karthikbalaguru <karthikbalagur...@gmail.com>
wrote:
> http://www.intel.com/design/intarch/papers/endian.pdf ->
> Refer the section "Merits of Endian Architectures" and the Table for
> clarifications w.r.t endiannes
>
[...]
> Java Virtual Machine*                   - Big-Endian

FWIW, this is a misleading, if not actually incorrect statement.  The
Java virtual machine is endian-independent, in that the architecture
is defined such that an implementation may use any byte order, and it
is impossible for a program running on it to determine which is in
use.  Software implementations typically use the endianness of their
underlying hardware.  Hardware implementations seem to normally be big-
endian, but there is no reason this is necessary.

Java's I/O libraries are defined to use big-endian order, but this is
a library issue, not an architectural one.

</jvm-implementor-pedanticism>

In article <TstUi.13993$lD6.12176@newssvr27.news.prodigy.net>,
Archi <z1@podzam.com> writes:
|> > In article <4721a047$0$3492$39db0f71@news.song.fi>,
|> > Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
|> 
|> > |> says: "The secondary stack is used to deal with functions that 
|> > |> return a variable sized result, for example a function returning an 
|> > |> unconstrained String. ... For most targets, the secondary stack is 
|> > |> growing on demand and is allocated as a chain of blocks in the heap".
|> > 
|> > And that is where they have made their mistake.  Where at all possible,
|> > it should be allocated as a separate segment.  There are two reasons
|> 
|> Nick, I would rather understand it differently - that GNAT stack
|> is not completely contiguous but contains linked chain of big
|> chunks, later suballocated in stack fashion. This involves
|> some work, but have some flexibility of heap. Your comment
|> assumes that every stack object is independently allocated.

Nope.  I stand by what I said.  Of course, I quite agree that no
such decisions are black and white, but only shades of grey.  There
are doubtless good reasons for their decision - indeed, I am pretty
sure that I know what they are, because I have implemented stacks
like that myself.

But, where we are at present (and where we could have been foreseen
to be going even a decade ago), the correct solution is a separate
segment.  Note that it wasn't the correct decision a decade ago,
because memory was too tight, but it was clear that (a) we were
going to 64 bits and (b) cache locality was going to become THE
memory performance issue.


Regards,
Nick Maclaren.

Nick Maclaren wrote:

> In article <4721a047$0$3492$39db0f71@news.song.fi>,
> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:

> |> says: "The secondary stack is used to deal with functions that 
> |> return a variable sized result, for example a function returning an 
> |> unconstrained String. ... For most targets, the secondary stack is 
> |> growing on demand and is allocated as a chain of blocks in the heap".
> 
> And that is where they have made their mistake.  Where at all possible,
> it should be allocated as a separate segment.  There are two reasons

Nick, I would rather understand it differently - that GNAT stack
is not completely contiguous but contains linked chain of big
chunks, later suballocated in stack fashion. This involves
some work, but have some flexibility of heap. Your comment
assumes that every stack object is independently allocated.

Archi

John L wrote:

>>That logic was also in the 360/91.  The 91 could do instruction
>>prefetch, including along the path of potential branches.

> Oh, yes.  That part they had to get right, unlike the interrupts when
> an operation generated a fault, e.g., divide by zero.  S0C0.

S0C0 is for multiple imprecise interrupts.

For those who don't know it, the 360/91 could execute instructions
out of order.  If an interrupt came in, it was necessary to finish
all the instructions that had already been started, possibly resulting
in more interrupts.  In addition, the address stored is likely not the
address of the actual instruction that caused the interrupt.

So, in addition to being able to execute instructions out of order
and prefetch along multiple paths it has to get the right answer,
assuming no program interrupts, with self modifying code.

-- glen

nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
> mojaveg@mojaveg.lsan.mdsg-pacwest.com (Everett M. Greene) writes:

> |> > |> If you're talking about separate stacks for return addresses and data,
> |> > |> there are C compilers extant using that method under the hood.
> |> > 
> |> > No, we aren't.
> |> 
> |> Are you going to give at least a hint as to what you are talking about
> |> then?
> 
> Read the earlier postings in the thread.  All will be explained.

It wasn't in the postings received here.

John L wrote:
>
> 
>>The Fortran library did use self-modifying code, though not the
>>immediately following instruction as far as I know.
> 
> 
> They certainly did a lot of stuff that seems silly now to save space.
> 

Reminds me of of an 8080 embedded application written in assembler when 
1k proms were expensive. System could crash in a certain routine if 
external inputs were in a transient "should never occur state". There 
wasn't room for kindly backing out of nested calls.

Solution, stuff "correct" value in stack pointer and jump to suitable 
location.

I came along when we had more prom and did things neatly.
Result, under that condition it would attempt to execute some store text 
messages.

>That logic was also in the 360/91.  The 91 could do instruction
>prefetch, including along the path of potential branches.

Oh, yes.  That part they had to get right, unlike the interrupts when
an operation generated a fault, e.g., divide by zero.  S0C0.

>The Fortran library did use self-modifying code, though not the
>immediately following instruction as far as I know.

They certainly did a lot of stuff that seems silly now to save space.

>It comes out, just as for the x86 INT case, if you want a routine
>callable from a high level language that will do SVC or INT.
>
>Otherwise, there isn't much reason to do it.

Agreed.  Still seems pretty exotic.

R's,
John