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

Secondary return registers #62

Open
lifthrasiir opened this issue Apr 21, 2012 · 6 comments
Open

Secondary return registers #62

lifthrasiir opened this issue Apr 21, 2012 · 6 comments
Assignees

Comments

@lifthrasiir
Copy link

The current ABI draft 2 specifies that "The CALLEE MUST return it's result, if any, in register A", but it does not specify anything about the return value which size exceeds 16 bits. I suggest to use register B for this use, as used by (for example) 0x10c-dev stdlib.

@ghost ghost assigned 0xabad1dea Apr 21, 2012
@kksym
Copy link
Contributor

kksym commented Apr 22, 2012

Is it completely essential that the function(s) in question have two return values, rather than returning a pascal-style string?

Say we encoded "Hello!" as a p-string, we would get (Assuming little endian, each table column is a word):

00060000'H''e''l''l''o''!'

Unless I'm missing something, I feel this would be the better solution for the library.

@lifthrasiir
Copy link
Author

@kk-: My initial version did use p-string, but someone objected to the idea. There is ongoing debate between p-string and c-string anyway, so I redesigned the interface to avoid the compatibility issue. Wrapping getline to return p-string or c-string should be easy though.

@kksym
Copy link
Contributor

kksym commented Apr 22, 2012

@lifthrasiir everyone seems to be more partial to p-strings as of current, however if you are thinking of abstracting upon this function then perhaps you could just hide this function away and expose the p-string and c-string interfaces. Internalising the function will effectively allow you to do as you please for as long as it's hidden.

@0xabad1dea
Copy link
Member

Ahh, I am getting back to this really late.

My instinct is to say that anything longer than 16 bit should just return a pointer but maybe that is not acceptable. Guess I need to get out some other ABIs and see how they return 64-bit ints on a 32-bit platform and do what they do.

@Blecki
Copy link
Contributor

Blecki commented May 9, 2012

Under the current ABI draft it's perfectly safe to return additional values in B and C. Since the caller must preserve the values of B and C if it cares about them, at worst, the caller will ignore the additional returned values. For anything larger you'll need to explore another calling convention or a heap/freestore implementation. Returning these values on the stack can be tricky if you also expect the caller to clean up any parameters that were passed on the stack.

I'd suggest returning by pointer for any value larger than two words.

@ghost
Copy link

ghost commented Jul 23, 2012

I suggest just returning a pointer to any value larger than three words - we have A B and C as possible return registers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants