Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Local words limited to 13 #600

Closed
Kaj-de-Vos opened this issue Dec 10, 2013 · 5 comments
Closed

Local words limited to 13 #600

Kaj-de-Vos opened this issue Dec 10, 2013 · 5 comments
Labels
status.built A change in codebase has been done to address the ticket. status.tested The change in code has been manually tested and verified to fix the issue. type.review Ticket describes a possible improvement.
Milestone

Comments

@Kaj-de-Vos
Copy link
Contributor

I have two projects that don't compile anymore:

Red []

f: function [
    p q r s t u v
][
    a: b: c: d: e: f: g: none
]

Compiling to native code...
*** Compilation Error: #code generation error: overflow in emit-variable
*** in function: exec/f_f
*** at line: 1
*** near: [
_function/init-locals 8
stack/mark-native exec/~f
stack/reset
stack/mark-native ~set
stack/mark-native
]

@dockimbel
Copy link
Member

Actually, the limit is 16 for the compiler (2 are reserved for internal use). The object branch added one more, and your code was using 14 already, so the limit is reached. The compiler maps each local word to a Red/System local word for simplicity and maximum efficiency. As the type is not provided, each Red/System local word takes 8 bytes by default (stack slot size for a float64!), so that the limit translates to 128 bytes on stack. This limit is currently imposed by the IA-32 backend, which use 8-bit displacements instructions relative to EBP (the stack frame pointer register), so effectively limiting the reach to a [-128, +127] bytes range.

Removing this limit can be done by using wider displacements, but resulting in more generated code and slower stack data accesses. So, in order to preserve the current speed, such wider displacements code generation should be done only when stack usage exceeds the range of 8-bit relative displacements. Such change is quite important in the IA-32 backend and might be needed also for the ARM backend (I haven't checked yet). Such upgrade was meant since the beginning but time was never found for it, although, it's an important one to have when Red will get ready for production usage. So, that change won't be done at once, but probably when enough spare time will be found for it, which could be as far as later in Q1 2014.

For the record, the interpreter has no such limit though.

@Kaj-de-Vos
Copy link
Contributor Author

Hm, IA-32 sucks again. I had that displacement range on my 6502 machines.

Thanks for the explanation.

@dockimbel
Copy link
Member

The new hard limitations for locals and arguments on stack are target-specific:

  • IA-32: 32KB max
  • ARMv5: 4KB max

So, for safe crossplatform apps, locals + arguments shouldn't take more than 4KB on stack, which translates to about 1000 32-bit slots or 512 64-bit slots (default is 64-bit slots if no type is specified in Red/System functions).

@dockimbel dockimbel added this to the v0.4.2 milestone Feb 14, 2014
@Kaj-de-Vos
Copy link
Contributor Author

That's a welcome improvement. Is that per function?

@dockimbel
Copy link
Member

Yes, per function.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status.built A change in codebase has been done to address the ticket. status.tested The change in code has been manually tested and verified to fix the issue. type.review Ticket describes a possible improvement.
Projects
None yet
Development

No branches or pull requests

2 participants