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

Targeting the CP1610 CPU for Intellivision possible? #39

Open
zezba9000 opened this issue Jan 7, 2019 · 5 comments
Open

Targeting the CP1610 CPU for Intellivision possible? #39

zezba9000 opened this issue Jan 7, 2019 · 5 comments

Comments

@zezba9000
Copy link

zezba9000 commented Jan 7, 2019

Hey we're having a discussion over at Atariage about the possibility of getting a C compiler to target the "CP1610" CPU. Ref: http://atariage.com/forums/topic/286670-sdcc-pic16-c-compiler/?p=4192163

Its a 16 bit CPU where sizeof(char) = sizeof(int) = sizeof(void*) = 1.
Is re-targeting for this CPU possible and if so are there any good docs or reference for what parts need to be changed in LCC to make this happen?

@ksherlock
Copy link

So everything is really 16-bits? ... run ops c=2 s=2 i=2 l=2 h=2 f=2 d=2 x=2 p=2 to generate the proper %term statements for the lburg file and update the sizes in the IR record appropriately. If LCC can't deal with non-8 bit chars, you could leave it as 8-bit and modify the lexer to essentially #define char int.

@zezba9000
Copy link
Author

zezba9000 commented Jan 7, 2019

Yep everything is addressed and stored as 16 bits.
Is the only file that needs to be looked at "lex.c" for this modification you're suggesting?
In short change the "int gettok(void)" method to change any findings of "char" to "int" tokens?

@zezba9000
Copy link
Author

Or can I just change "token.h" at line:
FROM: xx(CHAR, 3, 0, 0, 0, CHAR, "char")
TO: xx(INT, 3, 0, 0, 0, CHAR, "char")

@ksherlock
Copy link

You can run rcc -target=symbolic -charmetric=2,2,2 -longmetric=2,2,2 -ptrmetric=2,2,2 to get a sense for what happens if you just give them that size. (rcc is the compiler that runs after the preprocessor and generates assembly language.) string literals get a little screwed up -- they're packed but then padded with extra 0s at the end instead of inline. Try playing with that and see what happens.

@whizzter
Copy link

whizzter commented May 3, 2019

Sadly i don't think LCC is really suitable for this, LCC is quite "happy" to put things temporarily into memory in the symbolic dumps at least and this would probably hurt performance quite badly on slower CPU's (maybe i missed checking optimized builds?). Might be worth checking out SDCC (small device C compiler that has many backends) or the old PCC compiler to see if they are easy to adapt. As long as you don't need C++ there is quite a few options and while LCC is attractively designed this tendency for temporaries would not fly with those old CPU's. (If you want good performance with games that i suspect is the target?)

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

3 participants