Messages

1

Operating Systems and Porting / Re: Swiss finance regulator FINMA deputy CEO resigns, collateral damage from Debian?

« on: February 04, 2026, 03:08:01 pm »

Daniel, you keep locking threads after you post, preventing anyone from discussing it with you.  You also seem to have a habit of characterizing those discussions as "lies" when the person presents contrary evidence.  If you are going to advocate for free speech, don't shut it down when others present information that disputes your positions.

I do find it disingenuous that you were raising the issue of Google "astroturfing" when you characterize yourself as a "Debian developer," or had until this most recent post, and that you were forced to turn over dozens of domains that used the Debian name in them.  That might lead one to think you are associated with Debian, but are not.  Perhaps not the same as astroturfing, but deceptive none-the-less.

I am concerned about the obsession you have with Debian.  It seems extremely unhealthy and likely fills you with negative energy, affecting your health, and perhaps your loved ones as well.  I believe you would do better by creating the world you want to see, instead of trying to destroy the one others have built.  In the case of Debian, I see nothing but a sincere effort to create an inclusive and supportive community that welcomes diversity.  That certainly is a world I would want to see.

If you must campaign against injustice, and some people are compelled to, I do not think Debian is an embodiment of evil, unlike the persons controlling Executive Branch of the U.S. government and in other countries.  You should raise your voice against the institutional corruption practiced daily by the President of the most powerful country in the world.  There are many other organizations who do much greater harm to the world than Debian, even if one were to contemplate that perhaps they do (I do not).  Your focus could reveal the inherent corruption in authoritarian governments with close ties to large corporations that profit from such arrangements.

I do hope you find help for your needs, and I also hope that you see that many vulnerable people may be drawn into your efforts.  It is unfortunate that the far-right uses such vulnerabilities in people to try to find new recruits.  It seems that hate hates being alone, and I hope that is not your motivation.

tim
 

2

Firmware / Migrating the build environment/true portability

« on: February 04, 2026, 12:04:30 pm »

Hi All,
I wanted to again express my appreciation to Raptor CS for access to the hardware. I used that access to do a lot of bare metal testing as well as access to the lowest levels of the firmware, in an effort to build a truly portable build environment.  This has been a fantastic learning experience.  I sent the following summary to Raptor a few months ago, but then took some time off from computers and failed to post the summary to the forums (unless my memory is worse than I remember).

I have done a lot of digging into the internal boot process, specifically the SBE, and while in theory the boot process can be replaced, in practice this appears to be extremely labor intensive.  I have been working with Public Domain POSIX Make

https://frippery.org/make/

to rewrite the Makefiles to be strict POSIX 2024.  The GNU syntax in the Makefiles ties the build process very closely to GNU toolchain.  They are not compatible with FreeBSD's make.  The solution is strict POSIX 2024, but there are 28 Makefiles and 30 .mk files that need to be rewritten.

Note that strict POSIX 2024 does not support out-of-tree building, where the source code is in one directory and the object files are in another.  The main cause (effect?) of this is that implicit target rules can not use variables, so $(OBJDIR).o: is not a valid target.  The IBM writers of the SBE Makefiles leaned very heavily on GNU's extensions, to the point where I would describe the effort as "lazy."  I suspect at least a few of the Makefiles were generated by scripts.

I have rewritten several Makefiles, enough to dig deeper into the SBE build process.  The C++ implementation/includes on FreeBSD are not compatible with Linux's C++ implementation.  The naming for #ifndef is different, leading to duplication of std functions.  In a particular case, xip, the two source files are .C, but one of them does not contain any C++ while the other only contains five lines total, out of 3,237 in the file.  That file fails to compile because of the duplicate:

In file included from p9_xip_tool.C:41:
In file included from /usr/include/c++/v1/string:591:
In file included from /usr/include/c++/v1/__algorithm/remove.h:12:
In file included from /usr/include/c++/v1/__algorithm/find.h:16:
In file included from /usr/include/c++/v1/__bit/countr.h:15:
In file included from /usr/include/c++/v1/__bit/rotate.h:15:
In file included from /usr/include/c++/v1/limits:581:
/home/tkelly/raptor/talos-sbe/src/import/chips/p9/procedures/ppe/pk/../include/std/type_traits:46:19: error: reference to 'integral_constant' is ambiguous
   46 |         const _Tp integral_constant<_Tp, __v>::value;
      |

This failure appears to trace to

std::string i_ddLevelStr;   //Same

which is used as

ddLevel = strtol(i_ddLevelStr.c_str(), NULL, 16);

or similar for a total of two assignments and four references.  Again, the word "lazy" comes to mind.

There are deeper uses of C++, of course, such as

numRingIds = P9_RID::NUM_RING_IDS;

The namespace for P9_RID can be found in

src/import/chips/p9/utils/imageProcs/p9_ringId.C

I do not see anything that could not have been accomplished with C99 or later.  I suspect these files were designed to be compatible with AIX and IBM's compiler, not to be portable.  I have never seen any C++ code that could not be accomplished with C and a simpler compiler.

There are 391 files in the SBE that have C++ :: operators, totaling 8,178 lines.  I do not see this as being readily portable to C, and as a result of conflicts with other operating system and compiler implementations of C++, not really portable at all.

The native Linux build environment for the SBE can not compile successfully.  I suspect that within Raptor the build environment has been steadily patched and an attempt to build from scratch has not been undertaken in some time.  I suspect that even simple changes upstream could have a devastating effect on Raptor, should it occur in certain places or if certain people leave (and their knowledge with them).  This is an unfortunately common experience, and in large software efforts can lead to terrible inertia.

The sheer complexity of the boot process and dependency on external parties leaves me with no choice but to stop development.  This is not an easy decision to make.  I am partial to PowerPC, and enjoy working so close to bare metal.  However, I can not see a path forward while maintaining the simplicity I am trying to implement.

I am deeply concerned about the performance limits with the RISC-V chips I have seen, but their simplicity and low cost offers the hint of a path forward.  Personally, I would really be excited to see Raptor hardware running multi-core RISC-V, if the "open" philosophy can be maintained.  I am deeply concerned that many of the major players in the RISC-V and Open Compute sphere are the very same players that have undermined openness in tech for decades.  I rarely find a RISC-V SBC that isn't actually tied to blobs required to run the proprietary peripherals, and even entire toolchains are vendor-dependent.  Don't even think about asking if the firmware can be replaced.

As I previously noted in another post, the SG2000 chip was actually a surprisingly good performer for the 1w of power it consumed, although something was clearly impeding it, possibly the i- and d-caches being very, very small.  However, Pine64 and Milk-V were able to deliver boards for as little as $13.

Say it was possible to scale up to a 64 RISC-V core like the SG2000 (which I think is embargoed in the U.S. now), and it consumed 64 watts at peak power.  From my (homemade real-world integer-based) benchmarks, it would take 1.4 times to complete a parallel task as would a 16 core Raptor system (running SMT4), at half the power consumption (each one takes 76 times the elapsed time on the 64 thread Raptor system).  To me this hints of a cost-effective opportunity to scale multi-CPU, with some hardware enhancements.  Just a thought.

Again, my many thanks to Raptor CS and their efforts.

tim

3

Operating Systems and Porting / Re: $15B federal lawsuit vs. Google astroturfing in open source communities

« on: February 04, 2026, 11:08:57 am »

Welcome back, Daniel!  I was disappointed when you closed the thread containing our previous conversation.  You left after I pointed out that your lawsuits, of which this is another, have forced Debian to spend a great deal of money, some of which might have been spent on lifejackets and prevented the drowning death of a volunteer at a Debian event.

Just a reminder, you are continuing to use "Debian developer" in your signature in these forums, even though you were stripped of official developer status quite some time ago.  One might feel this is a misrepresentation of your position within the Debian community.

Speaking of which, after our previous conversation wrapped up, I was able to also correspond with Tiago Bortoletto Vaz, who is an actual Debian developer.  He reviewed our correspondence, and besides confirming that Debian has tried to reconcile and mediate with you, he confirmed Debian has also spent a great deal of money defending against your assaults on them.  We were also able to discuss Debian attempting to offer mental health counseling for its community members, although I do not know if there was any follow-through on their part.  They keep having to spend money defending against lawsuits, even some filed in European countries (both of which you lost).

You and I can agree on the harm that Google is doing to open source movements.  In addition to accepting $1 billion from Israel in assisting in identifying "targets," otherwise known as Palestinians, Google subverts projects towards their own goals.  Firefox comes to mind.  Even simple traffic monitoring while using Firefox shows inappropriate traffic being sent to Google while using the browser.  I advise human rights defenders to avoid Mozilla products completely, as they can not be considered safe.

We can also agree on the dangers of censoring free speech, given that people are being executing in the U.S. and elsewhere for exercising their right to free speech.   Saying "Defend the Constitutional prohibitions against illegal search and seizures" gets one labeled a "domestic terrorist" and killed, while the people doing the executions are said to be the actual victims by the authoritarian government.  I am disappointed that the response by the public was different when the gun-packing white male was killed subsequent to the poetry-writing lesbian soccer mom.  You've had some pretty severe criticisms of alternative sexual orientations within the Debian community, as I recall.

Regretfully, many of those being targeted are done so at the hands of people you have defended in your blogs, and we do disagree over "free" vs. "hate" speech.  I am disappointed but not surprised how often the very people spewing hate while claiming free speech shut down free speech in opposition to authoritarian governments as soon as they have obtained the power to do so.  For example, you closed the thread to prevent any further discourse from me, after I brought up your support for authoritarian figures and the clearly unresolved feelings over the death of your father.

But I digress.  Back to your post.  In reviewing the link, I find that it appears to be a front for your campaign, not an actual independent effort.  I suggest readers review Daniel's past posts and campaigns, and consider if you are being misled about why you are being told the truth.

tim

4

Firmware / Re: Cross-build compiler environment for SBE

« on: October 05, 2025, 11:38:45 am »

just a follow-up, I have abandoned my efforts to port the SBE to a strict POSIX make environment.  The issue is not the strict POSIX part, as that can be done with some work (53 files by my count, some of which migrate easily). 

The real issue is that the SBE code is not particularly portable.  Much of the hardware descriptions use C++ that could easily be implemented with structs, and the SBE relies on trivial (even lazy) C++ code in dozens of places that will not compile because the Linux implementation of C++ does not mesh well with the FreeBSD C++ implementation.  Libraries and namespaces are labeled differently, so included files are not found, leading to a failure to compile.  Fixing this would require an unreasonable amount of effort (over 8000 identified locations, plus the hardware descriptors), when there shouldn't even be any C++ code in something this close to bare metal.  None of the functionality causing issues requires C++, and would have been much more portable if written in C14 or even C99.  In some cases it is literally a std:: class to make a brief reference to a string.  Utterly unnecessary, and in my opinion, either lazy or intentional.

The code in question came from IBM; the choice to use C++ and how it is used leads me to believe there was not a true effort to open up the SBE.  The code released was built to a pretty specific environment, to the exclusion of others.  This is a direct (and very disappointing) example of how open source is not always free, as in "free to port and use in one's personal environment."  "Our way or no way" is not a choice, and without choices we are not free.

In my opinion it would be easier to construct a replacement to the SBE than to try to fix it.

5

Third Party CPU Discussion / Re: Why haven't we seen boards with Power9 / MicroWatt?

« on: October 02, 2025, 07:17:47 am »

You can already buy RISC-V systems today.

Milk-V
DeepComputing
framework

But the performance is really sluggish.

Yes and no.  I did a lot of work profiling several SBCs with ARM, RISCV and x86 CPUs.  I found that the SG2000-based Milk Duo-S had single thread performance comparable to the 1GHz ARM Wandboard Quad and Celeron-based Udoo x86 Advanced boards for general purpose tasks.  The difference is that the SG2000 used 0.6 watts at idle and 0.8 watts at full power, while the WB Quad used 2.7 and 3.4 watts and 9.1 and 10.1, respectively. Another difference is that the SG2000-based Milkv Duo-S cost $13.

Of course, both the Wandboard Quad and Udoo x86 Advanced have multiple cores, and easily outperformed the single core SG2000 in multithreaded tasks.  In most cases, the power use scaled with threads to the maximum core count, but less than 1:1 (it was more efficient to bring up additional cores).  I did the same tests on Raptor's POWER9 Talos II systems, and obviously performance was dramatically better, and the power usage was much higher, but not like the G5 and Cell systems I tested (both used over 100 watts at full power).  For comparison, I did the same tasks on a 1.25GHz Mac mini (PowerPC G4), and while performance was almost 1/3 better, it used 17.0 and 31.6 watts, respectively (and was faster than the 2.2GHz PowerMac G5 I tested).

I think the SG2000 suffers from very small i- and d-cache sizes.  Multicore support would obviously be a huge benefit.  What is also notable about the SG2000 is that the entire boot process can be replaced, including the firmware.  This is done as part of Lup Lee's successful efforts to port NuttX to the board.

Personally, while I am a huge fan of PowerPC/POWER architectures, in my efforts to port and/or build compiler and assembler pieces for the architecture, I have become dismayed at the sheer number of instructions the CPUs support. I have been reading through the OpenPOWER specifications, and with each version new instructions are added.  I feel like the "Reduced" part of RISC has been lost, and the boundary between CISC and RISC seems very blurry.  I have not been privy to the conversations about the additional instructions, but I do wonder if they are truly orthogonal and if they can maintain one instruction per cycle completion.  If there is evidence of stalls or synchronization issues, perhaps it would be better to let the compiler build more steps from fewer instructions.

In comparison, RISC-V sticks to a limited instruction set and maintains one instruction per cycle.  Yes, there is less pipelining and yes, no SMT-type re-use of CPU resources, but that also makes for a simpler design, which makes the entire production process cheaper.

I would really like to see a fully open PowerPC/POWER SBC with a goal of making it into a laptop and cellphone, targeting human rights defenders and other groups that are increasingly targeted by authoritarian governments.  Although the market size would almost certain make production units expensive, as the adage goes, freedom isn't free. 

6

Applications and Porting / Re: [DEV] Is there any tool to detect the logic that might be impacted by endianess?

« on: September 25, 2025, 08:26:20 am »

It does seem to me that seeing if the code will even compile in the projected build environment is a more immediate problem.

7

Applications and Porting / Re: [DEV] Is there any tool to detect the logic that might be impacted by endianess?

« on: September 20, 2025, 04:45:19 am »

I thought about this a bit more and maybe the authors of DOOM3 use their own vector intrinsics.  If you are wanting to port to big-endian, but they are using little-endian GPU-based vector registers, that would be where I would look for serious endian issues.  If I was hunting this down, I would be grepping for "vector" or "GPU" and looking to see what header files pop up.

8

Applications and Porting / Re: [DEV] Is there any tool to detect the logic that might be impacted by endianess?

« on: September 19, 2025, 04:59:03 am »

My thought is that endianness is so intrinsic to vector register function that scenes would not even render.  That is why any code that is expected to be portable would use compiler intrinsics to handle vector functions or any direct access to memory, as ClassicHasClass suggested. 

In my experience, just getting "portable" code to compile is an achievement.  I'd worry about it actually working later.  You might be worrying about a problem you don't actually have to solve right now.

Then again, I am not a fan of Asinine Intelligence, and my views are biased towards Actual Intelligence, so I probably should not be responding 

9

Firmware / Re: Cross-build compiler environment for SBE

« on: September 19, 2025, 04:51:57 am »

Ok, I installed the open-power sources from Microsoft's Github, but the build failed.

ppe42-gcc binutils fails with

../../ppe42-binutils/bfd/srec.c: In function ‘srec_bad_byte’:
../../ppe42-binutils/bfd/srec.c:254:26: error: ‘%03o’ directive writing between 3 and 11 bytes into a region of size 9 -Werror=format-overflow=]
  254 |         sprintf (buf, "\\%03o", (unsigned int) c);
      |                          ^~~~


The instructions for building ppe42-gcc say install the following patches:

https://github.com/open-power/op-build/blob/master/openpower/package/ppe42-gcc/0001-2016-02-19-Jakub-Jelinek-jakub-redhat.com.patch

https://github.com/open-power/op-build/blob/master/openpower/package/ppe42-gcc/0001-reload-Change-to-type-of-x_spill_indirect_levels.patch

These appear to be embedded within Microsoft's Github pages and not easily downloaded via curl -O.

I stopped here.  The line for me is I am not debugging GNU's binutils or gcc code or hunting around Microsoft's Github in order to build the environment to build the SBE.  There is a gambler's lure here, where maybe just maybe one more hour of effort will make it all work, but it never does.

10

Applications and Porting / Re: [DEV] Is there any tool to detect the logic that might be impacted by endianess?

« on: September 19, 2025, 03:48:22 am »

Most of the time I would not get any error but likely run into unexpected behaviour when running the game or apps.

Your verbs are unclear - "would not" and "likely run into" are future tense, as in, you are projecting what might occur.  Are you saying the entire code base compiled but has odd behavior when running in Big-endian mode?

If you can compile the source code, run it in Little-endian mode and see if the same unexpected behaviors are present.

11

Firmware / Re: Cross-build compiler environment for SBE

« on: September 19, 2025, 03:42:07 am »

I have not.  Certainly it looks like there are more instructions, but I gave up after getting internal compiler errors when ppe42-gcc tried to build ppe-binutils.  It was in the internal register allocator (ira) and both the subdirectory configure and Makefiles would not respect flags passed to them, as I documented at

https://forums.raptorcs.com/index.php/topic,617.0.html

However, I did not apply patches to what was in Raptor's source code tree.  Thank you for pointing out the different repository.

12

Applications and Porting / Re: [DEV] applying patches to old version of gcc

« on: September 15, 2025, 12:10:32 pm »

I think I am abandoning the efforts to build the SBE within ppe42-gcc.  The configure and Makefile files do not honor flags passed to them, which is making isolating the build failure very difficult.  I haven't even gotten to trying to cross-compile with the ppc eabi.  In addition to the previously documented issue where gcc 12 is not properly protecting flags passed on the command line to the top level make,

  ./configure --enable-stage1-languages=c,c++ --enable-languages=c,c++

shows up as

 Configured with: ../src/configure -v --with-pkgversion='Debian 12.2.0-14+deb12u1' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 ...

I am not sure what that means for my overall effort to port SBE to strict POSIX 2024 standards, but at this point, I am spending more time debugging what may be endless errors than actually moving forward elsewhere.  I have no interest in becoming an expert on configure nor gcc, just to figure out how something is supposed to work in the actual environment I will be using.

tim

13

Applications and Porting / Re: [DEV] applying patches to old version of gcc

« on: September 14, 2025, 12:56:33 pm »

I don't think this the -std issue.  It is in the register allocator used for coloring.  From my perspective, since this came from the Raptor git repository, and the code is compiling with gcc 12, but failing in a hardware backend part, I am missing something that helps configure the register allocator.  I'm thinking it should work out of the box once the -std flag is set, but it doesn't.

14

Operating Systems and Porting / Re: FreeBSD 14.3 available on bare metal Raptor Talos II

« on: September 14, 2025, 12:39:21 pm »

I did early testing on bare metal using big-endian FreeBSD, but ultimately I decided to install little-endian on the machine to align with Raptor's internal development (they pointed out that the PCI bus is little-endian, as well).  There is a lot that is transparent to the bi-endian POWER9 CPU.  I successfully ran handrolled big-endian Altivec code both on bare metal FreeBSD as well as within a QEMU VM running on little-endian Debian (it failed on bare metal little-endian Debian, of course).

I did not try graphics; I only need the computational power.  However, it would be good to have that option.

15

Applications and Porting / Re: [DEV] applying patches to old version of gcc

« on: September 14, 2025, 12:22:31 pm »

The compiling of ppe42-gcc with gcc 12 now proceeds until another error in a different part.  Although this is not the same as the original thread (trying to patch older gcc), this will work until it doesn't.

And it doesn't.  After compiling gcc, the build attempts to use it to build libgcc.  The following is the error message from configure:

Checking multilib configuration for libgcc...
Configuring stage 1 in powerpc64le-unknown-linux-gnu/libgcc
configure: creating cache ./config.cache
checking build system type... powerpc64le-unknown-linux-gnu
checking host system type... powerpc64le-unknown-linux-gnu
checking for --enable-version-specific-runtime-libs... no
checking for a BSD-compatible install... /usr/bin/install -c
checking for gawk... gawk
checking for powerpc64le-unknown-linux-gnu-ar... ar
checking for powerpc64le-unknown-linux-gnu-lipo... lipo
checking for powerpc64le-unknown-linux-gnu-nm... /root/raptor/ppe42-gcc/host-powerpc64le-unknown-linux-gnu/gcc/nm
checking for powerpc64le-unknown-linux-gnu-ranlib... ranlib
checking for powerpc64le-unknown-linux-gnu-strip... strip
checking whether ln -s works... yes
checking for powerpc64le-unknown-linux-gnu-gcc... /root/raptor/ppe42-gcc/host-powerpc64le-unknown-linux-gnu/gcc/xgcc -B/root/raptor/ppe42-gcc/host-powerpc64le-unknown-linux-gnu/gcc/ -B/usr/local/powerpc64le-unknown-linux-gnu/bin/ -B/usr/local/powerpc64le-unknown-linux-gnu/lib/ -isystem /usr/local/powerpc64le-unknown-linux-gnu/include -isystem /usr/local/powerpc64le-unknown-linux-gnu/sys-include   
checking for suffix of object files... configure: error: in `/root/raptor/ppe42-gcc/powerpc64le-unknown-linux-gnu/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.

I dug into the config.log and created a file with the test code, then ran it manually with -v

  /* confdefs.h */
  #define PACKAGE_NAME "GNU C Runtime Library"
  #define PACKAGE_TARNAME "libgcc"
  #define PACKAGE_VERSION "1.0"
  #define PACKAGE_STRING "GNU C Runtime Library 1.0"
  #define PACKAGE_BUGREPORT ""
  #define PACKAGE_URL "http://www.gnu.org/software/libgcc/"
  /* end confdefs.h.  */
 
  int
  main ()
  {
 
    ;
    return 0;
  }


...
GNU C (GCC) version 4.9.2 (powerpc64le-unknown-linux-gnu)
   compiled by GNU C version 12.2.0, GMP version 6.2.1, MPFR version 4.2.0, MPC version 1.3.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 29fbe43bf124570f80365dc213e4e677
conftest.c:1:0: internal compiler error: in i, at ira.c:503
   /* confdefs.h */
 ^
unrecognized DWARF version in .debug_info at 6

conftest.c:1:0: internal compiler error: Segmentation fault
unrecognized DWARF version in .debug_info at 6
xgcc: internal compiler error: Segmentation fault (program cc1)
unrecognized DWARF version in .debug_info at 6
Segmentation fault

The code in question

      for (n = 0, i = 0; i < FIRST_PSEUDO_REGISTER; i++)
        if (TEST_HARD_REG_BIT (temp_hard_regset, i))
          ira_non_ordered_class_hard_regs[cl][n++] = i;
      ira_assert (ira_class_hard_regs_num[cl] == n);

The assertion fails.  I dug into FIRST_PSEUDO_REGISTER and found in this particular build it comes from gcc/config/rs6000/rs6000.h

 933: #define FIRST_PSEUDO_REGISTER 149

Adding some debugging code to gcc/ira.c

      for (n = 0, i = 0; i < FIRST_PSEUDO_REGISTER; i++)
        if (TEST_HARD_REG_BIT (temp_hard_regset, i)) {
fprintf(stdout, "i = %d, cl = %d, n = %d\n", i, cl, n);
          ira_non_ordered_class_hard_regs[cl][n++] = i;
         }
fprintf(stdout, "after cl = %d, ira_class_hard_regs_num[cl] = %d,  n = %d\n", cl, ira_class_hard_regs_num[cl], n);
      ira_assert (ira_class_hard_regs_num[cl] == n);
    }


results in
FIRST_PSEUDO_REGISTER = 149, LIM_REG_CLASSES = 23
before cl = 22, ira_class_hard_regs_num[cl] = 48,  n = 48
i = 0, cl = 22, n = 0
i = 3, cl = 22, n = 1
...
i = 72, cl = 22, n = 51
i = 74, cl = 22, n = 52
i = 75, cl = 22, n = 53
after cl = 22, ira_class_hard_regs_num[cl] = 48,  n = 54
host-powerpc64le-unknown-linux-gnu/gcc/conftest.c:1:0: internal compiler error: in setup_class_hard_regs, at ira.c:509
   /* confdefs.h */

What appears to have happened is that an earlier setting of ira_class_hard_regs_num has been altered and a check has failed. Not all registers have TEST_HARD_REG_BIT set so some are skipped, and it appears that some do have the bit skipped but this is unexpected.

From reading the documentation in ira.c, I strongly suspect I need to set some additional flags during the build process, but I can not find instructions on this.  Anyone have suggestions?

tim