Created attachment 395438 [details, diff] New MIPS targets for catalyst I can't subscribe to the gentoo-catalyst mailing list right now, so I am attaching this patch as a bug. It is independent of the other patches I'll be filing as bugs shortly. This patch updates arch/mips.py to support the following new targets: (MIPS II Big-endian) mips2 (MIPS IV, R12000+, Big-endian) mips4_r12k_plus mips4_r12k_plus_n32 mips4_r12k_plus_n64 mips4_r12k_plus_multilib (MIPS II Little-endian) mipsel2 I am not sure why the mips2/mipsel2 targets were missing. I thought they were added years ago. The *_r12k_plus targets are for use when the target system (usually an SGI system) has either an R12000 or R14000 CPU (maybe hopefully in the future, R16000). In this instance, -march=r12000 -mno-fix-r10000 is passed to gcc to disable the R10K ll/sc WAR that causes gcc to emit branch-likely instructions to avoid a silicon errata in R10000 v2.6 and earlier CPUs. Since R12000/R14000's came long after those processors, they already have the specific errata fixed and can use standard branch instructions, which are slightly quicker to execute (and which were removed in MIPS R6, but that doesn't apply to these machines anyways). It also fixes up the whitespace so that everything aligns better.
(In reply to Joshua Kinard from comment #0) > I am not sure why the mips2/mipsel2 targets were missing. I thought they > were added years ago. Pretty sure I removed them at some point. They're useless. There aren't any mips2 machines we'll ever run on. > The *_r12k_plus targets are for use when the target Remove the _plus. With those things fixed, the patch seems good to me.
Created attachment 395506 [details, diff] New MIPS targets for catalyst v2 True, we'll never support the R6000, since it only exists in a large supercomputer that now lives in a museum. But MIPS-II is the branching point for MIPS32R* and MIPS-III, thus I've felt it was more suitable as a base porting stage than MIPS-I, since we'll probably never support R2000/R3000 machines with Gentoo (I don't want to know how long gcc will take on those platforms -- Debian can probably attest to that). I actually think Debian's mips packages are all MIPS-II now -- they migrated off of MIPS-I around Lenny (I think, but I can't find a reference). In any event, I don't think it's an issue keeping that target around -- just a few lines of Python. But if that bit isn't accepted, I can still patch my local catalyst copy fairly easily. Patch updated to remove the "_plus" bits (I thought that was better than a literal "+" character").
Further thinking on it, I wonder if the MIPS target classes couldn't be converted to say, a class factory and a dict that keys by target name. It'd be simpler to have a generic base class that returns a generated class derived from info stored in a dict. The only real differences are the class names and the CFLAGS, and that can *easily* be converted into a dict. Probably have to fiddle with the __metaclass__ property a bit. I'll have to research it some and see if that might be able to trim mips.py down a fair bit or not.
Yeah, we have plans to do the change from classes to maybe even a confiparser or json file. A dictionary would suit a json file easily.
(In reply to Brian Dolbec from comment #4) > Yeah, we have plans to do the change from classes to maybe even a > confiparser or json file. A dictionary would suit a json file easily. Not json please. I don't see anything wrong with just a dict.
If I remember correctly, the original idea was to make them config files using configparser to load them. It is just data, easily loaded when needed, that doesn't need to be in python classes like they currently are.
I think the original issue is done. I'm closing this. Reopen if there's more to discuss.
(In reply to Anthony Basile from comment #7) > I think the original issue is done. I'm closing this. Reopen if there's > more to discuss. Was Kumba's patch committed?
I certainly didn't. I've been busy with portage and layman releases. I do intend to apply it to master. I was not sure if it is something that needs another 2.X bump for. Checking just now, no it hasn't been applied to 2.X, master, pending, 3.0 branches.
(In reply to Brian Dolbec from comment #9) > I certainly didn't. I've been busy with portage and layman releases. > > I do intend to apply it to master. I was not sure if it is something that > needs another 2.X bump for. > > Checking just now, no it hasn't been applied to 2.X, master, pending, 3.0 > branches. Sorry, I think I got confused with another issue. Thanks for catching that Matt. I assumed it was something for the 2.x branch. I can commit it there. Should it go into any other branches? I only follow the 2.x branch for my releng work so I'm not too familiar with the workflow.
(In reply to Anthony Basile from comment #10) > (In reply to Brian Dolbec from comment #9) > > I certainly didn't. I've been busy with portage and layman releases. > > > > I do intend to apply it to master. I was not sure if it is something that > > needs another 2.X bump for. > > > > Checking just now, no it hasn't been applied to 2.X, master, pending, 3.0 > > branches. > > Sorry, I think I got confused with another issue. Thanks for catching that > Matt. > > I assumed it was something for the 2.x branch. I can commit it there. > Should it go into any other branches? I only follow the 2.x branch for my > releng work so I'm not too familiar with the workflow. Okay I committed this to the 2.x branch. You can cherry-pick it from there: commit 1082054caa75f3162fdad811d787aaffe3d7d643 Author: Joshua Kinard <kumba@gentoo.org> Date: Tue Feb 10 06:57:18 2015 -0500 arch/mips.py: update MIPS targets Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
seems to be in master now: http://gitweb.gentoo.org/proj/catalyst.git/commit/?id=2091f3e3c2fee8d6ccf0f322b9dfbc461ba26e5c
