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

rcm2024 - initial headers #2482

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from
Draft

rcm2024 - initial headers #2482

wants to merge 1 commit into from

Conversation

feilipu
Copy link
Collaborator

@feilipu feilipu commented Jan 25, 2024

I'm adding headers for the rcm2024 (a r2ka CPU machine, with RC2014 bus).

I'm using the newlib mechanism to generate headers for private asm, public asm, and C, for both the r2ka CPU and for the optional rcm2024 bus interface modules

Not too comfortable putting the target related headers into the include/arch/r2ka directory. Probably there should be separate target related header configurations directory in classic (like newlib), where a target can pick its own header configuration files, and mash them together with the CPU related header configurations.

Thoughts and input welcome...???

@feilipu feilipu marked this pull request as draft January 25, 2024 11:00
@feilipu feilipu self-assigned this Jan 25, 2024
@suborb
Copy link
Member

suborb commented Jan 30, 2024

I'm resigned to the fact that although they're called targets, the headers are in the arch/ folder - this was chosen to match newlib.

If the ppide etc headers aren't just for the r2ka then there's an argument to moving them into a common arch/bus/rcbus directory

@feilipu
Copy link
Collaborator Author

feilipu commented Jan 30, 2024

If the ppide etc headers aren't just for the r2ka then there's an argument to moving them into a common arch/bus/rcbus directory.

I've been mulling this argument (for too long now).

There are three cases.

  1. The intrinsic CPU registers for z180, r2ka, r4k, etc. These will never change but will appear for every target, though for 8080/5 and z80 these are minimal.
  2. Hardware or devices with registers or typical implementations like ppide or tms9918 etc. These will probably also be constant but may appear across multiple targets.
  3. The target itself that needs to have a CPU frequency, how the I/O and memory is configured, etc. These will be target specific (by definition).

So I am uncomfortable to smash them all in the include/arch/ directory, though that's where they all are now.
And, since there's a config directory needed for the m4 files to generate headers, it will need to hide somewhere too. Perhaps that means an arch/device/ directory?

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

Successfully merging this pull request may close these issues.

None yet

2 participants