Hi,
I am trying to bootstrap mlton via polyml. This is working well on x86_64, but failing on ARM. I am getting this error:
Exception- InternalError: fixupOffset: jump too far (16-bit offset) raised while compiling
Exception- Fail "Exception- InternalError: fixupOffset: jump too far (16-bit offset) raised while compiling" raised Exception- Fail "Exception- InternalError: fixupOffset: jump too far (16-bit offset) raised while compiling" raised
# Error-Structure (Main) has not been declared
Found near PolyML.shareCommonData Main.mainWrapped PolyML.export ("mlton-polyml", Main.mainWrapped) Error-Type error in function application. Function: PolyML.shareCommonData Main.mainWrapped : unit Argument: PolyML.export : string * (unit -> unit) -> unit Reason: Value being applied does not have a function type Found near PolyML.shareCommonData Main.mainWrapped PolyML.export ("mlton-polyml", Main.mainWrapped) Error-Structure (Main) has not been declared Found near PolyML.shareCommonData Main.mainWrapped PolyML.export ("mlton-polyml", Main.mainWrapped) Static Errors
This seems to be a fundamental limitation of the interpreter. Is there any kind of workaround? Could the interpreter be extended to allow for longer jumps?
Thanks,
Adam
On 23/04/2013 01:07, Adam Goode wrote:
Hi,
I am trying to bootstrap mlton via polyml. This is working well on x86_64, but failing on ARM. I am getting this error:
Exception- InternalError: fixupOffset: jump too far (16-bit offset) raised while compiling
This seems to be a fundamental limitation of the interpreter. Is there any kind of workaround? Could the interpreter be extended to allow for longer jumps?
You may be able to work-around this by setting PolyML.Compiler.maxInlineSize to something smaller. Presumably you have a very large function and that may reduce the code size by not inlining other functions into it.
The better solution is, of course, for the interpreter to support longer jumps. The code of the interpreter hasn't really been looked at for a very long time. It was originally written to allow the native code version to be bootstrapped onto new hardware and so it really only works to the extent necessary for that. It is much slower than it should be and I really should revisit the whole thing.
David
Bad news, I tried PolyML.Compiler.maxInlineSize := 1 and it still fails.
Any other ideas? If I were to work on 32-bit jumps, are there binary compatibility issues you can think of?
Thanks,
Adam
On Tue, Apr 23, 2013 at 5:06 AM, David Matthews <David.Matthews at prolingua.co.uk> wrote:
On 23/04/2013 01:07, Adam Goode wrote:
Hi,
I am trying to bootstrap mlton via polyml. This is working well on x86_64, but failing on ARM. I am getting this error:
Exception- InternalError: fixupOffset: jump too far (16-bit offset) raised while compiling
This seems to be a fundamental limitation of the interpreter. Is there any kind of workaround? Could the interpreter be extended to allow for longer jumps?
You may be able to work-around this by setting PolyML.Compiler.maxInlineSize to something smaller. Presumably you have a very large function and that may reduce the code size by not inlining other functions into it.
The better solution is, of course, for the interpreter to support longer jumps. The code of the interpreter hasn't really been looked at for a very long time. It was originally written to allow the native code version to be bootstrapped onto new hardware and so it really only works to the extent necessary for that. It is much slower than it should be and I really should revisit the whole thing.
David
polyml mailing list polyml at inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
On 24/04/2013 15:20, Adam Goode wrote:
Bad news, I tried PolyML.Compiler.maxInlineSize := 1 and it still fails.
Any other ideas? If I were to work on 32-bit jumps, are there binary compatibility issues you can think of?
I think there could be problems because the offset used in the instruction that loads a value from the constant area at the end of the code is also 16-bit. That limits the distance from that instruction to the end of the code. However, it looks as though the jump instructions use signed 16-bit offsets where the other cases use unsigned. I've committed a change that uses unsigned 16-bit offsets for jumps and splits the 16-bit jumps into forward and backwards cases. Could you try this and see if it works? You will need to build the compiler (make compiler) to pick up the change. If not you're welcome to see if you can come up with a fix.
David
I built from svn trunk last night, and still had the same problem. So, no luck. Thanks for trying!
Adam
On Thu, Apr 25, 2013 at 7:49 AM, David Matthews <David.Matthews at prolingua.co.uk> wrote:
On 24/04/2013 15:20, Adam Goode wrote:
Bad news, I tried PolyML.Compiler.maxInlineSize := 1 and it still fails.
Any other ideas? If I were to work on 32-bit jumps, are there binary compatibility issues you can think of?
I think there could be problems because the offset used in the instruction that loads a value from the constant area at the end of the code is also 16-bit. That limits the distance from that instruction to the end of the code. However, it looks as though the jump instructions use signed 16-bit offsets where the other cases use unsigned. I've committed a change that uses unsigned 16-bit offsets for jumps and splits the 16-bit jumps into forward and backwards cases. Could you try this and see if it works? You will need to build the compiler (make compiler) to pick up the change. If not you're welcome to see if you can come up with a fix.
David
Just to be absolutely clear: you did run "make compiler" after running "make", didn't you? You should get Poly/ML 5.5.1 Development before the prompt.
David
On 26/04/2013 20:29, Adam Goode wrote:
I built from svn trunk last night, and still had the same problem. So, no luck. Thanks for trying!
Adam
On Thu, Apr 25, 2013 at 7:49 AM, David Matthews <David.Matthews at prolingua.co.uk> wrote:
On 24/04/2013 15:20, Adam Goode wrote:
Bad news, I tried PolyML.Compiler.maxInlineSize := 1 and it still fails.
Any other ideas? If I were to work on 32-bit jumps, are there binary compatibility issues you can think of?
I think there could be problems because the offset used in the instruction that loads a value from the constant area at the end of the code is also 16-bit. That limits the distance from that instruction to the end of the code. However, it looks as though the jump instructions use signed 16-bit offsets where the other cases use unsigned. I've committed a change that uses unsigned 16-bit offsets for jumps and splits the 16-bit jumps into forward and backwards cases. Could you try this and see if it works? You will need to build the compiler (make compiler) to pick up the change. If not you're welcome to see if you can come up with a fix.
David
Oh no, I messed that up. I will try again. Thanks for noticing. On Apr 26, 2013 3:43 PM, "David Matthews" <David.Matthews at prolingua.co.uk> wrote:
Just to be absolutely clear: you did run "make compiler" after running "make", didn't you? You should get Poly/ML 5.5.1 Development before the prompt.
David
On 26/04/2013 20:29, Adam Goode wrote:
I built from svn trunk last night, and still had the same problem. So, no luck. Thanks for trying!
Adam
On Thu, Apr 25, 2013 at 7:49 AM, David Matthews <David.Matthews at prolingua.co.**uk <David.Matthews at prolingua.co.uk>> wrote:
On 24/04/2013 15:20, Adam Goode wrote:
Bad news, I tried PolyML.Compiler.maxInlineSize := 1 and it still fails.
Any other ideas? If I were to work on 32-bit jumps, are there binary compatibility issues you can think of?
I think there could be problems because the offset used in the instruction that loads a value from the constant area at the end of the code is also 16-bit. That limits the distance from that instruction to the end of the code. However, it looks as though the jump instructions use signed 16-bit offsets where the other cases use unsigned. I've committed a change that uses unsigned 16-bit offsets for jumps and splits the 16-bit jumps into forward and backwards cases. Could you try this and see if it works? You will need to build the compiler (make compiler) to pick up the change. If not you're welcome to see if you can come up with a fix.
David
I tried again, and did "make compiler". Even with 5.5.1 Development, and maxInlineSize:=1, MLton is just too big for polyml:
Exception- InternalError: fixupConstantLoad: constant too distant (16-bit offset) raised while compiling
Adam
On Fri, Apr 26, 2013 at 5:14 PM, Adam Goode <adam at spicenitz.org> wrote:
Oh no, I messed that up. I will try again. Thanks for noticing.
On Apr 26, 2013 3:43 PM, "David Matthews" <David.Matthews at prolingua.co.uk> wrote:
Just to be absolutely clear: you did run "make compiler" after running "make", didn't you? You should get Poly/ML 5.5.1 Development before the prompt.
David
On 26/04/2013 20:29, Adam Goode wrote:
I built from svn trunk last night, and still had the same problem. So, no luck. Thanks for trying!
Adam
On Thu, Apr 25, 2013 at 7:49 AM, David Matthews <David.Matthews at prolingua.co.uk> wrote:
On 24/04/2013 15:20, Adam Goode wrote:
Bad news, I tried PolyML.Compiler.maxInlineSize := 1 and it still fails.
Any other ideas? If I were to work on 32-bit jumps, are there binary compatibility issues you can think of?
I think there could be problems because the offset used in the instruction that loads a value from the constant area at the end of the code is also 16-bit. That limits the distance from that instruction to the end of the code. However, it looks as though the jump instructions use signed 16-bit offsets where the other cases use unsigned. I've committed a change that uses unsigned 16-bit offsets for jumps and splits the 16-bit jumps into forward and backwards cases. Could you try this and see if it works? You will need to build the compiler (make compiler) to pick up the change. If not you're welcome to see if you can come up with a fix.
David
-
adam＠spicenitz.org -
David.Matthews＠prolingua.co.uk