FW: Porting OpenJDK 6 to Stratus OpenVOS on IA32 -- %EBP and the HotSpot server compiler

Barnes, Richard Richard.Barnes at stratus.com
Thu Dec 3 11:41:26 PST 2009

There is a comment in
ameGuess.java that says that EBP is not guaranteed to be valid for
compiled code.  In the context of this code that fact is considered a
nuisance for debugging, but not a show-stopper.

For OpenVOS, this fact could cause real problems in that our stack
conventions require that at least one of two conditions for all code
being executed is true:

*	%EBP is the frame pointer for the current stack frame or the
code for this procedure must not have modified %EBP.

*	The code must be covered by what we call a block_map and
entry_block that describes how the size of the stack frame for the code
is calculated.  (This allows us to use %EBP as something other than a
frame pointer unless the frame size is variable.)

I am assuming that it is probably too hard to get the server compiler to
generate a block_map and entry_block, which we did get GCC to do,  So,
what we are wondering is whether there might be an easy way to get the
server compiler to either use %EBP as a frame pointer or to not modify
it at all.  I note that both GCC and our native OpenVOS compilers have
both internal and external switches that allow us to do just that.  If
no such switch exists, would there be a way to modify the server
compiler or a table it uses to get the behavior we desire?

If not, is there any reliable way we can walk the stack without these


Richard Barnes
Senior Technical Consultant
Stratus Technologies

> ______________________________________________ 
> From: 	Barnes, Richard  
> Sent:	Friday, September 12, 2008 4:31 PM
> To:	'porters-dev at openjdk.java.net'
> Cc:	'Joe.Darcy at Sun.COM'; Richard Barnes
> Subject:	Porting OpenJDK 6 to Stratus OpenVOS on IA32
> I am part of a small team at Stratus Technologies that is planning to
> port OpenJDK6 to its proprietary OpenVOS operating system running on
> IA32.  What makes this interesting and unusual is that even though we
> are targeting a little-endian chip, for compatibility reasons OpenVOS
> must present a big-endian environment to its users, so that gcc and
> g++, as well as native OpenVOS compilers, produce code that makes IA32
> appear to be big-endian at the source level.  The internals of OpenVOS
> are quite different from the internals of Unix, but we have added a
> POSIX.1 API to our operating system in recent years, which should help
> to make this project possible.  The runtime conventions are close to
> those of Unix on IA32, with the exception of endianness and some
> register usage, but that should not be insurmountable.
> When I first sent mail to jdk-6.dev, Joe Darcy of Sun suggested that
> we check in with this group for community advice.
> For these reasons, we hope to have our project accepted to join
> OpenJDK.
> Thanks,
> Richard Barnes
> Senior Technical Consultant
> Stratus Technologies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/porters-dev/attachments/20091203/10a785a6/attachment.html 

More information about the porters-dev mailing list