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

Enable all address sizes for CPU none #939

Closed
pinobatch opened this issue Sep 25, 2019 · 4 comments
Closed

Enable all address sizes for CPU none #939

pinobatch opened this issue Sep 25, 2019 · 4 comments
Assignees

Comments

@pinobatch
Copy link

@pinobatch pinobatch commented Sep 25, 2019

I sometimes use ca65 to write code in assembly language for an obscure CPU for which I do not want to write a whole assembler from scratch (example: #362). When I do this, I .setcpu "none" and implement every mnemonic as a ca65 macro.

However, I get Error: Range error when the assembler cannot statically prove that a particular value is less than $100. When I use .globalzp to assert that the value is less than $100, I get Warning: Symbol `memset_tiny' is absolute but exported zeropage. When I do .segment "LOWCODE0": zeropage to make a label not absolute, I get Error: Invalid address size specification for current CPU.

What would be the drawbacks of making all three address size specifications (zeropage, absolute, and far) valid for the none CPU?

@polluks
Copy link
Contributor

@polluks polluks commented Sep 27, 2019

This is the particular code

/* Not supported by None and Sweet16 */

Loading

@greg-king5
Copy link
Contributor

@greg-king5 greg-king5 commented Oct 2, 2019

I think that the original idea is that the none CPU has no instructions; therefore, it has no addressing modes. But, that makes it useless! I agree with you; we should go in the opposite direction. none should have no limits -- even "long" addresses should be allowed.

Loading

@greg-king5 greg-king5 self-assigned this Oct 2, 2019
@oliverschmidt
Copy link
Contributor

@oliverschmidt oliverschmidt commented Oct 2, 2019

I fully agree. @greg-king5: Thanks for taking care.

Loading

@greg-king5
Copy link
Contributor

@greg-king5 greg-king5 commented Oct 2, 2019

Done: 2e5fbe8.

Loading

@greg-king5 greg-king5 closed this Oct 2, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants