Is the ia16 support planned to be upstreamed someday?

[LowLevelMahn]

you are currently based on gcc version 6.3.0 any fix reason for that or is a mainline merge in the future possible?

do you think that your work can get upstreamed some day?

[tkchia]

Hello @LowLevelMahn,

Yes, this is something that I hope will happen. However, I think I will defer to Mr. Jenner --- the original maintainer of the gcc-ia16 port --- on when and how to get it upstreamed. This will probably take a while.

Thank you!

[LowLevelMahn]

far more questions...

1. now that gcc is officially gitted, would it be a good idea to base your development on a branch from https://gcc.gnu.org/git (or the github mirror), tag: releases/gcc-6.3.0? to ease later reintegration Info: releases/gcc-6.3.0 seems not to be the exact version, there are many small differences outside of ia16 changes, also gcc-6.2 and gcc-6.4 are different, i don't what the real base is for example this test file is different:

https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/testsuite/c-c%2B%2B-common/cpp/pr63831-1.c;h=c9e7756406de43bbf1df3b1cc143b35448dcf878;hb=91c632c88994dca583bcd94e39cd3eba1506ecfe

got a different head-line

https://github.com/tkchia/gcc-ia16/blob/gcc-6_3_0-ia16-tkchia/gcc/testsuite/c-c%2B%2B-common/cpp/pr63831-1.c

Update: seems that all these small changes are needed to get the tests etc. going - could become tricky to get this into the mainline :(

2. ever thought about upgrading to later releases of the gcc code base like latest of 6, 7, 8, 9 or most recent - or are there too many changes needed to upgrade?

[lpsantil]

Don't more recent gcc's generate a ton of binary code when compared to the older releases?

[LowLevelMahn]

Don't more recent gcc's generate a ton of binary code when compared to the older releases?

why should recent release produce more binary code?

[tkchia]

Hello @LowLevelMahn,

I have not yet tried porting the IA-16 back-end to a recent version of GCC (e.g. GCC 9 or 10), so I do not yet know how easy or hard this is. I hope to try this some day.

Thank you!

[mfld-fr]

@LowLevelMahn : What is the reason behind your 'rebase / update' request ? Today several IA16 projects switched to @tkchia version. It works quite well, not really obsolete (6.3 issued on 2016-12-21), and @tkchia already works hard to support all of us. Why don't you try yourselves and push a PR to move on 6.5 as a first step ? That way you would understand it is not a finger snap...

[LowLevelMahn]

i fully understand that upgrading is not a finger snap - could cost hours, days to adapt to all the api changes

i've got two interrests:

1. how to map the ia 16 changes to the official git (without loosing history) the current repo is based on early svn2git conversions on the gcc github mirror, the official git is based on reposurgeon and contains changes like different submitter-name/email adrs, changed submitt-messages etc. - nothing big but these two repos have just no common commits -> everything will be adaptable to this development at any time later

sooner or later every github gcc mirror based project need to switch to the official git - or else you're not able to pull or update changes directly to mainline - the github gcc mirror is not official

what was i wrong about:

i though ia 16 was branched from the gcc 6.3 release branch (because of the name) but it is still in mainline - so upgrading is just a merge with later submits from gcc mirror on github and updating to 6.4 or 6.5 just makes no sense - these are bug-fix branches - unrelated to ia 16 source branch

so everything is stated in previous post was just wrong, so i deleted the comments

2. upgrade to later version - slowly in very tiny steps, just to try it

[mfld-fr]

I am afraid you did not answer my question... let me restate it then: what is the benefit for you and for us to spend (probably much) time in upgrading current code to... let us say 7.x version ? Serious and not workaround-able bug ? Missing feature ?

[LowLevelMahn]

I am afraid you did not answer my question... let me restate it then: what is the benefit for you and for us to spend (probably much) time in upgrading current code to... let us say 7.x version ? Serious and not workaround-able bug ? Missing feature ?

-for the fun of it -tkchia: "Yes, this is something that I hope will happen", " I hope to try this some day" -when do you upgrade your compiler? -needed, if there is even any interrest in becoming part of mainline someday -upgrading becomes more and more complex and time-consuming, already 3 major version between ~6.3 and current

but for now i just want to figure out whats needed to get into a official git repo base, that seems hard enough

[mfld-fr]

Okay, so please put your hands in to figure out, and push a PR with your upgrade proposal, to help all of us assessing the workload and check if the upgrade is worth considering the benefit / cost ratio.

I am sorry to tell that your posts brought more noise than added value for now, but I would be happy to revise my opinion while reviewing your next PR...

[LowLevelMahn]

I am sorry to tell that your posts brought more noise than added value for now, but I would be happy to revise my opinion while reviewing your next PR...

sorry for that, my primary goal is for now to find out what is needed for the repo-switch

btw: there is a 7.1-ia16 branch in this repo, even more up to date with master then tkchia branch - i don't know if that was just a test or something

[LowLevelMahn]

is there even interest in switching to the official git repo? (means disconnect from unofficial github gcc mirror)

[tkchia]

Hello @LowLevelMahn,

To quote Mr. Jenner (https://gcc.gnu.org/ml/gcc/2018-06/msg00105.html):

It's not trivial, though - the current implementation has some middle-end changes which would need thinking through and doing properly to avoid polluting that code with ia16-isms.

I might update it and have another try at upstreaming it at some point if nobody else does it first, but I have too much else going on at the moment so it would likely be a year or two (maybe more) before I get to it.

From my experience, the main difficulty is that the GCC middle-end --- which is machine-independent, and is used across all architectures --- is primarily tailored towards

machines with a flat (non-segmented) byte addressed data address space (the code address space can be separate). Target ABIs may have 8, 16, 32 or 64-bit 'int' type.

(from the GCC Internals info file, info gccint). To get GCC to even support something resembling segment:offset far addresses, in addition to tweaking the machine-specific back-end, I ended up also having to hack the machine-independent (!) middle-end, and unfortunately the hacks were not very neat (and still are not).

Thank you!

[LowLevelMahn]

I ended up also having to hack the machine-independent (!) middle-end, and unfortunately the hacks were not very neat (and still are not).

ok that sounds really difficult - wasn't aware of this - so in the end there are just not that many low hanging fruits where i can help with my limited time in think :(

[tkchia]

Hello @LowLevelMahn,

So I think this will be --- at the very least --- one of the issues with getting IA-16 support mainstreamed: the changes needed to support IA-16 far addressing, a "medium" memory model (far text + near data), distinct data and stack segments, etc. --- all these can potentially affect the design of the middle-end which is shared across all GCC-supported architectures.

And I think this is why Mr. Jenner hopes to at least rethink the design of the middle-end changes, before going any further. (And I agree in principle, even if at the moment I myself am not sure how to go about it.)

Thank you!

[tkchia]

Hello @LowLevelMahn,

ok that sounds really difficult - wasn't aware of this - so in the end there are just not that many low hanging fruits where i can help with my limited time in think :(

Well, yes, unfortunately things are that tricky. If the IA-16 port were just an additional back-end that can be simply be tacked on to GCC, things would be a lot easier. Thank you!

[LowLevelMahn]

sounds like upgrading could "cripple" the middle-end even more without any benefit for getting mainlined, sorry for so much noise

AND the github mirror is already updated with the new official git repo, are you still able to pull from github gcc mirror? the submit hash keys are not equal anymore

[LowLevelMahn]

Update: still work in progress (while im getting better and better with git)

following brings the IA16 develop branch back in sync with official repo

git clone https://github.com/tkchia/gcc-ia16.git
git clone git://gcc.gnu.org/git/gcc.git
cd gcc
git remote add gcc-ia16 ../gcc-ia16
git fetch gcc-ia16 # warning no common commits
git checkout gcc-6_3_0-ia16-tkchia
git rebase --onto releases/gcc-6.3.0 4b5e15daff8b54440e3fda451c318ad31e532fab

after this is the gcc-6_3_0-ia16-tkchia branch based on the official repo/main so its possible to merge/pull again from official git repo

TODOs: -Should be the other way around so that not the repo changes completely -Subbranches missing (tests, 7.1 test branch etc.)

git branch -a shows all the branchens

these seems to be related

  remotes/origin/gcc-6_2_0-ia16
  remotes/origin/gcc-6_3_0-ia16
  remotes/origin/gcc-6_3_0-ia16-tkchia
  remotes/origin/gcc-6_3_0-ia16-tkchia-far-vars
  remotes/origin/gcc-6_3_0-ia16-tkchia-medium-model
  remotes/origin/gcc-6_3_0-ia16-tkchia-prot-mode
  remotes/origin/gcc-6_3_0-ia16-tkchia-regparmcall-option
  remotes/origin/gcc-6_3_0-ia16-tkchia-regparmcall-reg-stdarg
  remotes/origin/gcc-7_1_0-ia16
  remotes/origin/gcc62-ia16
  remotes/origin/ia16-port
  remotes/origin/tkchia/auto-float-stdio
  remotes/origin/tkchia/far-stack
  remotes/origin/tkchia/far-stack-free-ds
  remotes/origin/tkchia/medium-model-take-2
  remotes/origin/tkchia/rewrite-bp-as-bx
  remotes/origin/tkchia/segelf-hpa
  remotes/origin/tkchia/split-elks-multilibs  

any other? i just want to merge all