Feature Request discussion: Should we split J1 variants and builds into separate git branches?

[RGD2]

I've also been meaning to think up a better organisation for where the j4a can live... maybe as a never-merged-to-master sub-branch so it can benefit from being in the same tree as the j1a, rather than being side-by-side as it is.

The reason being, as it is, when changes happen to j1.v, they currently need to be manually propagated into j4.v and so on (which happened with the subtractor recently added, and is kinda made worse by having separate tops for the different build targets), and the idea is to remain at least swapforth-level code compatibility with the j1a.

(Excepting in the io address space... but that's also a common issue for ports to different boards )

Since the idea is to 'stay attached' to the j1a's code base, so as to allow upgrade/downgrade paths, it might not be too bad to just keep the j4a as an unmerged git branch of the j1a.

Or, just keep it in my github fork - but I am loathe to unintentionally end up as a non-compatible fork, when I don't want nor need to do so.

Hmm.

After some thought, I realised this might also be a good way to handle the other j1 variants and hardware platforms too - just have a separate branch for each variant, and sub-branches for each build target (with possibly sub-sub-branch for each different physical board.)

That way it should be much easier to keep the variants from drifting apart, and the whole codebase will be much clearer as well (fewer subdirectories) and it establishes the code-of-conduct for introducing dependant variants like the j4a. ( I'm already thinking about doing a 24 bit datapath version of the j4a, with 1M addresses via 2 or 3 external SRAM's - expanding the PC to 20 bits, so it sits between a 16 bit and 32 bit j1 architecture - more space, but still no DRAM with it's cycle stealing refresh shenanigans. it would be a sub-sub-variant, so it stays in synch with the j4a. Call it the j4a24 perhaps.)

It could also be used to attach and share application swapforth code as well, which would be ideal, and also allow git to be exploited to handle sharing/merging/etc between derived-app codebases too.

So anyway, what are people's thoughts Re this keeping-unmerged-branches idea?

[bmentink]

Yes good idea. Branches would be the right way I feel, especially if there is a lot of shared code.