OSDev.org

Ok - well, that makes some degree of sense - SOME degree. I haven't heard of employers doing a deep dive into the entirety of the open source code base looking for programmers to hire. Have you? And nor have I seen people removing the author's name from public domain code - even though yes, they can. Have you? I saw it happen once with my own code base where someone created a new source file (exeload.c) and put their name as the author, and then copied and changed my code as they brought it across. It wasn't done to eliminate my name, it was just to reorganize, and I'm the one who checked it in, so I could have said something and/or put my name in, but I didn't, as it was indeed a new file, and - whatever - she was doing great work, and is welcome to use my PD code as a base for her new file (in my project even!).

Either way - if this entire copyright caper is an employment advertising scheme, and makes the difference between starving to death or not in a capitalist society, it's the first I've ever heard of it. You're probably more likely to be struck by lightning than get a job offer because you slapped a copyright notice on code instead of making it public domain so had a slightly higher chance of keeping your name intact. I do get contacted via my Linkedin profile. And I've been contacted by ex-colleagues before. But I've never seen a job offer of "yeah, we saw your source code while trolling through sourceforge and thought 'why not?'". I once had a plan to automate all my bill payments, and switch on the lights automatically, and be a recluse so that when I died, no-one would know I was dead and I would "live" for decades and keep getting letters from the Queen after I turned 100. And someone told me that believe it or not, the Queen doesn't spend her time going through the birth registry looking for people who have turned 100 so that she can send them happy birthday messages - you need to actually apply. It's probably the same with job positions.


Let me rephrase. Can you point to one byte in my executable that is from GCC's runtime code. I don't link in any of their material at all. And the only code that comes out of GCC - all assembler - is what it saw as C code going in - which I provided.


The lawyer is just one opinion. I will be subjected to the opinion of any judge worldwide. And if there is no copyright holder, the prosecution is going to be in the most difficult position to argue their right to sue me. If there is an undisputed copyright holder, they are in a much stronger position.

This isn't necessarily for me personally. It's for others to be in the strongest possible position if I was to ever attempt to sue them. If someone else thinks one of the copyrighted versions gives them a better legal standing in their lawyer's opinion - fine - go for it - I don't care - go and use their code. But if their lawyer has the same opinion as me - then they now have the PD option.

Regardless, that's why - no, I need, or at least want, a public domain version of the code - not something that has a copyright notice slapped on it, which is indeed the case for that floating point code.

BTW, in Australia, our constitution says that the Governor-General controls the Navy, which is totally not the case. It also has no mention of freedom of speech, but when the government passed a law that was sort of a violation of free speech - only sort of (a ban on political advertising on TV I think), the High Court decided that there was an "implied" right to free speech in the constitution. So I'm used to judges making up any old crap they want, and documents not being worth the paper they are written on. So I'm expecting a crapshoot when I enter a random court, and just have to hope that the judge is reasonable. And I doubt that I am the only person in the world who is more comfortable about going into court where I'm being sued by an author who has made zero attempt to claim copyright, and every attempt to get the code in the public domain. That's what I want for myself, it's what I provide for others, so that's why I am after a public domain replacement, regardless of whether or not you and presumably others have no problem with undisputedly copyrighted code being linked into your executables. I'm not trying to stop you or others from using libgcc and their floating point routines - go for it - I don't care. But I don't want to be involved in other people's hair-brained (in my opinion - or as far as I can tell) employment schemes.

I only asked for public domain code, not an explanation as to why, in your amateur legal opinion applicable worldwide, there is nothing wrong with linking in undisputedly copyrighted code because it has the FSF seal of approval and if you can't trust the FSF - who can you trust?

Let me put it another way.

I link my executables with pdld - which is public domain - so gcc has no ability to directly put anything into my executables - regardless of any license or non-license they/you claim/believe they have put on their code. So for any code internal in gcc to arrive in my executable, it needs to go through the assembly step (I compile all C code with "-S").

All of my code is basically a variation of this:

D:\devel\pdos\pdpclib>type foo.c
void foo(void)
{
bar();
}

There is nothing magic.

So here is the generated code:

@ Generated by gcc 3.2.3 C90 V9.X for ARM/pe
.file "foo.c"
.text
.align 0
.global _foo
_foo:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 1, uses_anonymous_args = 0
mov ip, sp
stmfd sp!, {fp, ip, lr, pc}
sub fp, ip, #4
bl _bar
ldmea fp, {fp, sp, pc}^


Let me annotate it.

> @ Generated by gcc 3.2.3 C90 V9.X for ARM/pe

They could potentially claim copyright over that line.
It's at least an English sentence that they originally wrote and I have since modified.
But that line disappears after I run it through the assembler.

> .file "foo.c"

This disappears after the assembly, and in addition, the word "file" is not copyrightable, and "foo.c" I created myself. Although I got that name from elsewhere, and theoretically it could be trademarked - but that's not copyright, which is under discussion.

> .text

This disappears, but admittedly does reappear in the final executable. It would be a very harsh judgment from the court that this is copyrighted material, and regardless, I don't think the FSF were the first to write this word with a dot in front of it.

> .align 0

This disappears before hitting my executable.

> .global _foo
> _foo:

The word "global" disappears before reaching my executable. The word "foo" potentially remains - but that's my code, so my property to do with as I please.

> @ args = 0, pretend = 0, frame = 0

Disappears before hitting the executable.

> @ frame_needed = 1, uses_anonymous_args = 0

Disappears before hitting the executable.

> mov ip, sp

Ok, so this code was generated after gcc detected that I had declared a function.

If they can claim copyright over this instruction then all bets are off - Microsoft could also claim copyright over the output of any "copy" command issued by any user anywhere in the world.

You could argue this is a more elaborate transformation, which indeed it is, but it's a transformation of my copyrighted code. If they get to claim copyright over that then yeah, all bets are off. FSF owns half the world.

> stmfd sp!, {fp, ip, lr, pc}
> sub fp, ip, #4
> bl _bar
> ldmea fp, {fp, sp, pc}^

Ditto the rest of the code. And I can see I neglected to put -mapcs-32, which caused me a lot of headaches.

And that's the end of the file.

Unless you want to claim that FSF has the power to decide what can be done with code that they have transformed from C to assembler, they have nothing to say whatsoever about what I do with my executables. And that situation existed before they came up with that "runtime exception" thing. So long as you don't link any of their code in - which I don't, and haven't for decades - they have no say whatsoever about what I can or can't do with my executables - even if they wanted to, which you are claiming they say they don't want to, but I trust them about as far as I can throw them. Which is the same distance I trust Australian judges who find "implied rights" whenever it is convenient for them rather than having to go through the enormous effort to change the Australian constitution like anyone else has to do.

That's why when I decided to write an OS (1994-04-28), I immediately switched to writing the C library first.

BFN. Paul.

GCC runtime exception says:


Given that GCC generates names for the floating point maths operations that are implemented in its Runtime Library, the executable generated thusly can be said to depend on an interface provided by the Runtime Library, even though the executable may not otherwise be based on the implementation (because we chose to copy the implementations of those operations from some-where else, instead of relying on the Runtime Library to provide them).


Constructs (except, as described above, related to the IR of the compiler) produced by a compiler for the consumption of assembler, loader, or linker are, in addition to the final executable, also covered under this exception.


The compilation process in question here is "Eligible" because it is done using GCC.


Given that your executables (Independent Modules) depend on the names (interface provided by the Runtime Library) of the soft-float functions (if not their implementations), you are benefitting from the GCC Runtime Library Exception that, despite the copyrights, allows you to use the names of those functions.

---


The copyright from GPL applies to the names of those math functions also. (There's no need to go look into the implementation or its copyright, regardless of whether it belongs to GCC or not.)
---

You are over-doing by trying to remove even those pieces of GCC that the Runtime Library exception specifically allows within your executable. If such a rigid is your stance against GPL, why use software released under GPL as your build environment.

Crikey. That didn't even cross my mind. You think they can copyright the NAMES of those functions? Where there's smoke, there's fire (supposedly). So if you think that, then a judge may think that too, so it would perhaps be prudent for me to hop into the gcc 3.2.3 code (my fork) and change the names to something the you, and/or the FSF and/or a random judge agree is not named by them and thus not copyright by them.

However ...

D:\devel\pdos\pdpclib>grep divsf map.txt
map.txt: 0x412460 ___divsf3

D:\devel\pdos\pdpclib>hexdump pdptest.efi | grep __

D:\devel\pdos\pdpclib>hexdump pdptest.efi | grep -i div
014C40 7365730A 00000000 44697669 64652062 ses.....Divide b

D:\devel\pdos\pdpclib>

... those names don't make it into the executable either.


I don't believe that is correct, but it will be up to a random judge to decide that.

You're supposed to copyright a work of art anyway. Not some meaningless technical internal names.


Well - that's a separate debate and I haven't really provided an opinion here, but the current debate is not about GPL in particular, it's about any copyrighted code whatsoever. It destroys the whole purpose of PDPCLIB which is to provide a public domain C library with zero restrictions whatsoever. I'm not saying that that is useful to anyone in particular, and I'm not particularly saying there is anything wrong with people writing or using copyrighted freeware. It's their free time, they are welcome to do whatever they want. They're not my slaves. I'm just explaining why I personally don't want to touch it. And if I'm the only person in the world who feels that way - that's fine by me too. But given that plenty of others write no-quibbling public domain software, I'm guessing I'm not alone.


As opposed to using what?

In 35-55 years, no-one has been willing to release a C90-compliant compiler into the public domain.

Everyone with the skills to do so keeps it closely guarded with a copyright notice.

Even while people insist how easy it is to do.

I've seen a lot of skilled people try and fail to reach C90 compliance. I'm not very good with algorithms so I have trouble (ie I literally failed - at least within reasonable timeframe) to fix a reproducible error in SubC (which is the closest thing to a C90-compliant compiler we have in the public domain). There's also cc64 which is much closer to C90, but we only have generated source code for that, and it's x64 target only. That may have now been replaced by mm64, but still generated code, so won't buy me much so haven't attempted to upgrade to that yet.

And we've been trying for decades to get to C90.

Oh - there's also a public domain one for the Z80 - forgot the name - but Z80 only and I don't think it is C90-compliant.

And it goes downhill from there (Small C or whatever).

A C compiler at least good enough to compile PDPCLIB and PDOS (both C90-compliant) is the last remaining thing for an entire public domain solution. All the other tools (pdmake etc) are public domain. We just collectively don't have the skills to write a C90-compliant compiler written in C90.

I don't think that changes anything. GCC is generating those names to interface with its Runtime Library. Regardless of what you name them, the "interface" (as represented by those names) is still being made use of at least from the GCC's end. You can blame my earlier interpretation, but the Runtime Library exception did explicitly specify "interface" and not "names used to represent those interface".

Moreover, I believe that the interface would not only consist of the names emitted within the assembler output, but also those assembly instructions that participate in passing of the arguments to and returning of the result from those routines. Not the instructions themselves, but their use in building up to the call to the soft-float routine; how and in what order the parameters are to be passed and the results to be returned is defined by the interface. I think consulting Google vs Oracle could be of benefit to see if that applies here; but that was about fair-use, not about removal of copyrights, afaiu.

Assuming that the interface is still present in your assembler-output (and hence in the final binary), the Runtime Library Exception prevents the viral nature, as you describe in your philosophy, of GPL from applying to your application. But the second clause in the Exception likely prevents you from stripping away the copyrights:



I understood this as: One is being allowed the use of the interface under the Exception, and apply the licensing conditions of the Independent Modules, but one cannot claim that the interface is now stripped off of its copyrights.



As Octocontrabass mentioned in one of the earlier posts, it is indeed about starvation. Most people (including corporations, even more so) don't have the luxury of building works of art to give away in public domain. If there's a lack of decent C compiler in public domain, that's likely the reason.

Are there any commerical compilers that let go of their copyrights when pieces of their code get embedded within the client executables?

These days, there's plenty of research material, books, articles available on compiler technologies to seek help from. If one doesn't care about the optimizations at all, and one restricts oneself to 1-2 architectures, one can walk the AST, and generate self-contained instructions, while keeping parameters/local vars/temp vars/etc all on stack, and loading/storing them into/from registers as needed. The performance would be abysmal, but that should give a starting point. I am also not saying that writing these is easy. Writing lexer and parser by hand for a C like langauge is drudgery. What may work is developing thin vertical slices of the compiler - a bit of lexer to support a small construct, a bit of parser to parse that construct, a bit of type-checking and conversions for that construct, a bit of code generation (input to the assembler) for that construct. Once that is done, repeat these steps with another construct that one wants to support.

---

Is there any reason to stick with C?
Couldn't you use some language that is simpler than C, for which you could write an interpreter that gets loaded when the executables run?
For e.g. Forth, or Lisp, or Scheme, or even a byte-code similar to Java's?

I believe there's also a language that's based completely on the 'sub' x86 instruction (edit: just found out, subleq is its name, though these are termed as not languages but OISC one-instruction set computer), and yet another that's based on 'mov' x86 instruction, these individual instructions being (I believe) labelled as capable of generating Turing-complete computations.

IMHO, these are all more interesting than C, and allow for an oppurtunity to avoid GCC, at least once the tools are built with the assurance that they themselves do not run afoul the 2nd clause of the Exception.

---
I agree that the definition of interface isn't as simple as just the names.

I believe that using the Exception does not allow one to weaken the copyleft (copyright) nature, let alone strip it away entirely, of anything that's part of GCC's source code but got embedded in the compiler's output.

I believe that is an extremely harsh interpretation. However, once again, I (or anyone else) would be facing a judge who likely knows nothing about computers except how to watch porn, and he may indeed have that exact interpretation (ref High Court of Australia making up crap even when nothing at all exists), so yes, you are highlighting the need to get away from GCC which I have been conscious of for decades.

And I think it is a harsh interpretation because a generated function call sequence is not a work of art and I don't believe is subject to copyright at all. It is generated machine code (or ends up as that after assembly), from a "machine" in a different language. The machine was not fed a (copyrighted) work of art to produce what you are trying to identify as a work of art (thus subject to copyright). BTW, they had this problem early on with computers - the binaries weren't considered copyrightable because they didn't look anything remotely like a work of art or the original undisputed art (the source code). So the law had to be amended to cater for this new phenomenon. But now you're moving to machine-generated quasi-art being copyrighted by the builder of the machine.


I don't have an expectation of a corporation to give away a C compiler. I have an expectation that at least one person in the world for the last 35-50 years would have seen the need for a C compiler and made their freeware C compiler public domain rather than put it under a job-hunting license. I mean seriously - do you think someone would publish a public domain C compiler and then someone else would remove the name and we'll never figure out who the original author is in order to give him the (non-existent) job instead? Sounds like Superman/Clark Kent "glasses on, glasses off".


Sure. And not one person, worldwide, has a combination of the skills and willingness to make a public domain one.


I am attemting to complete my suite in the original language I started with - ie C90.

When that job is complete, I may then repeat the entire process, switching to Pascal, or Rust, or whatever the flavor-of-the-day is. Or maybe I'll decide to write hand-optimized assembler.

I haven't yet completed the C90 phase.


I can simply write in the SubC subset of C90 to do that.

I am permanently at a crux where I am wondering whether we'll never find someone with the required skills and willingness, and that I should start dumbing down my code to the SubC standard.

What I have done is the next best thing. I have SubC sitting there on the UC386 disk with the ability to recompile itself so that I can indeed produce a pure public domain distribution, but if you want to fix a bug in the OS, you first need to bring the compiler (SubC) up to speed. And you have all the tools to do that available. You can use SubC to bring SubC up to speed, so that's not an issue.

And I also have the next best thing to the next best thing. UCX64 is able to rebuild itself using cc64 so you can fix bugs in the OS. The only catch there is that in order to fix bugs in the C compiler, you basically need to write a C compiler. Or bring SubC up to speed, and this time it might be more challenging than on the 80386 due to the non-stack calling convention of the x64.


I have "Sector C" already, and I have written a C version called "Multisector C". I didn't really understand the algorithm, but I understood it sufficiently. So yes, one of the things I will potentially do is start with Sector C language and try to fight my way out. I suspect I'll be dead before that happens though. I'm 56 currently. And as you can see, I am still busy with other things I think have higher priority currently.

The use of the instructions is guided by the design of the interface. For e.g. for calculating exp, whether or not the the exponent is passed first, whether it is passed directly or through a pointer, etc. Given that we do not yet know the extent to which the term "interface" is defined within the Exception, assuming the worst-case seems appropriate to me.

Does gcc's 'intention' to call into the Runtime define the beginning of one end of the interface?

If all the infrastructure for calling into Runtime Library and the Runtime Library itself, are removed from GCC, and replaced by call to a single entry-point into your own library (something like a system-call interface) that provides the implementations of the routines, does that help? The interface is sufficiently different from GCC's, and therefore its usage will also differ from GCC's. There won't be a Runtime Library to speak of.

Another 'solution' that just popped up: During compilation, when the compiler generates the call to those math routines, figure out which line in *your* source code caused GCC to emit them. For e.g. say it is double-floating point '+' operation. In your code, replace that '+' with a call to the public-domain implementation of the double-floating point '+' operation that itself does not rely on double-floating point '+' from GCC. This is just working around the problem one level up - don't allow GCC to even generate those calls. Does that work?

---



Would the author themselves be able to use their own work in a setting different than public domain? If not, they are not going to put their best work, or any work at all, out there.



True. The lives of most of the people have to be very 'optimized' - there's not much room for mistakes that may harm their day-job or cause them to get entangled in legal matters. Would Chris Lattner write a public domain compiler, and risk scrutiny by his previous employers like Apple who hold copyrights on the work he did while he was employed there? What exactly does he have to do, to ensure that his public domain compiler does not conflict with his prior work that he doesn't own? Would Apple have retained him if he had insisted on keeping his work in public domain?



My suggestion was not choosing the flavor-of-the-day language, but a language that is simple to implement an interpreter for, so that this dependency on GCC can be avoided. Didn't Apple hire Chris for similar reasons of avoiding GCC - they weren't comfortable with GCC's licensing? But in our case, us being single individuals, can't afford to pay some-one like Chris to build a public domain compiler. I guess that even after he (or other compiler devs) retires from all this, given that he would not own much of his work on LLVM, he wouldn't be allowed to replicate such a compiler (or a skeleton thereof) in public domain.


There are still options, as the one about not allowing GCC to even generate the calls to RuntimeLibrary, that can be considered before anything that is so subtantial that may affect your health.

The only public interface that gcc advertises is the C90 etc standard, which they don't attempt to claim ownership of and it is unclear if AT&T could claim ownership of if they attempted to. The internal/external functions (adddf3 etc) are not meant to be directly called and are not of interest to anyone at all except someone doing something unusual like I am. There would have to be something novel about them in order for them to patent them if they did want to protect those. gcc 3.2.3 was published in 2003 so if they had attempted to patent anything - which I highly doubt - it would have expired by now regardless.


There already is no runtime library to speak of already. The only thing is a clone of a subset of their runtime library, which at least currently has the same interface.


That's basically writing a partial compiler. So yes, if there is a very harsh judge, who thinks the same way as you, or thinks like the High Court of Australia which just makes up any old crap to suit their personal preferences, that would "work" unless you start getting harsher and harsher interpretations like there is an "implied right" of FSF that no-one should be able to be "inspired" by the existence of their C compiler and they may as well put the Governor-General in charge of Sydney Rail while they're at it. That's also "implied" when you have control of the Navy.

But for me, "work" stops at the reasonable level which I have already done which is remove any actual object code from my executables. Yes, I've implemented AT&T's API. Yes, I've implemented GCC's internal libgcc API. It's a harsh interpretation to even suggest that FSF is attempting to claim copyright of the internal API itself, but even if they are attempting to do that - which I doubt - they're not likely to be able to be successful in exercising such a right/implied right. So I'm already comfortable enough personally. To use it until SubC comes up to speed, anyway.


Yes, absolutely. The same as they can use Shakespeare's "Hamlet" in any setting whatsoever. There is no-one to seek approval from.


I'm not expecting people to put their best work out there at all. Not for free. I'm just expecting something very basic so that it at least exists.


This isn't a question about one individual. I'm talking about people who write a free one anyway - for whatever reason someone is willing to do volunteer work - and irrespective of past work - but then insist on slapping a copyright notice on it.


Replacing "public domain" with "freeware" - that is a separate issue that people need to decide on. As far as I am aware, it is freedom of thought/speech for me to write a body of code that does something identical to some paid commercial work I did. The algorithm used certainly isn't copyrightable - only patentable. I don't think anyone can stop you from doing your best to paint the Mona Lisa (or some other painting in copyright) as you remember it either. At that point it's your brain, your speech, your painting. You presumably can't have it sitting next to you as you draw your painting though.


I don't think that is correct. It would be a violation of freedom of speech for him to not be able to write a C compiler outside of someone else's employment. Your employer doesn't get to take away your human rights. The most I've heard of is someone not being able to work for a competing company, or opening a competing company, within x months/years of leaving an employer, but that has nothing to do with copyright, and you do effectively enter into a contract to give up what would normally be considered your human right. But I don't think that is even legally enforceable. But you signed it anyway, so you should presumably need to live up to a gentleman's agreement at least. I guess it could be worded as "competing product". But again - that contract has an end date as far as I know.


Sure, but the risk of FSF suing me (actually, that's not something I seriously think is going to happen - what I want to do is be in a strong position to debate with people like right now) for cloning the internal interface of their functions needs to be weighed up against the much larger risk of dying in a car accident. And I've yet to meet one person who refuses to get into a car because they found out last year's road toll and would rather walk instead. In NSW/Australia they have a "double demerits" scheme for long weekends. It's completely pointless - people don't die at a higher rate - but for whatever reason the media likes to publish the death toll from long weekends, so someone made stiffer penalties (everything doubled). And people do indeed warn you "oh - watch out - it's double demerits". Not one person has ever said to me "oh, be careful this Easter - last Easter x number of people died - you might be next!".

And people warn me to not post personal information on the internet because supposedly there is a massive number of murders/rapes/abductions that happened purely because of a Facebook post, not because the victim lived next door and was already known. But when I press them for the number to find out whether it's larger than the road toll - which they don't give a **** about when they are faced with walking or catching public transport - all I hear are crickets chirping.

So yeah - keep it in perspective, and don't read too much into my position. I'm pretty sure that the FSF won't suddenly start suing people for linking libgcc into their executables. But then again I've been pretty sure about lots of things and been flat out wrong. Like a US president would ever claim US elections were fraudulent after he lost. And an ex military general (Flynn) goading him to declare martial law because it's "no big deal". And the majority of Americans apparently not finding that problematic and about to elect him again. I was and remain shocked to the core. What's more problematic is that I wasn't able to predict that, and got my prediction entirely wrong. I apparently have some sort of problem with my knowledge-gathering technique or something which still hasn't been corrected. I live in the Philippines currently. Maybe tomorrow I will find out that 99% of Filipinos were closet NPA supporters all this time and I now live under a communist dictatorship and I'm not allowed to leave and I'm jailed for being a western capitalist pig-dog.

So I am indeed looking for "clean" executables - but I've already achieved that to my satisfaction. This ARM floating point was an anomaly - I didn't expect that a processor wouldn't have hardware floating point available. Or in this case, apparently require privilege to enable.

What I haven't achieved is a clean toolchain - the C compiler being the Achilles Heel - so close but yet so far.

You need to copy the libgcc API for your library to have the same interface, and at least in the United States, courts have not decided whether copyright applies to APIs.

Actually, that could be a bigger legal problem than just using libgcc in the first place, because the permissions granted in GCC's runtime library exception only apply to compiled code, not source code. You have permission to link your compiled public-domain binary with libgcc and release the combined binary as public domain, but you don't have permission to copy libgcc's APIs into your source code and release it as public domain.


It's pretty safe to say the FSF does not want copyright to apply to APIs, since all those free-software Unix clones rely on copying lots of non-free Unix APIs.


Why waste time writing an unnecessary libgcc replacement when you could be working on your compiler that doesn't need libgcc in the first place?


How is a C90 compiler "very basic"? Didn't you just say a few posts ago that you tried writing one and got stuck because it was so difficult? It may be "very basic" compared to a compiler for some other language, but that doesn't mean it's easy!


If you actually did that, you'd almost certainly end up with code that's similar enough to the commercial work to count as copyright infringement, even if you didn't literally copy the code.


The Mona Lisa is public domain.


The copyright holder absolutely can stop you, unless you're such a terrible artist that the copyright holder doesn't recognize it.


He didn't even win by majority the first time, if he wins a second time it won't be by majority.


I'm not familiar with ARM, so I can't tell you what's going wrong, but I can tell you that you should be able to use the FPU on every ARM platform you've mentioned so far. Even Android, since armeabi-v7a guarantees FPU support.

Sure. And people are copyrighting trivial header files too, like the ELF structures, so anything you write is near-identical. It should be sorted out, and I'm standing by, similar to the movie "Juggernaut", waiting to see which wire needs to be cut to proceed. If the judge says the variable names all need to be changed, I'll do a global change. If the judge says more needs to be changed, I'll do that too. My software suite is (almost) self-sufficient so I can create executables incompatible with everything else in existence if that's what the judge says.


1. So I can get an immediate result.
2. Because it's within my skill level.
3. I don't believe it is unnecessary - a compiler I write will be in the same boat of needing soft floating point routines.
4. People have the option of using the superior gcc instead of my C compiler, while still ensuring their executables are completely clean as far as anyone knows for sure.


Basic tools. People are always telling me why don't I move on to C-whatever instead of staying with C90. I keep explaining I haven't managed to reach C90 yet. Just getting to that very first level of the standard is a huge effort.

BTW, I have never attempted to write a C compiler. Or an assembler. Or a linker. I have fixed bugs in other people's though. What I said is that I have watched very talented people fall short. Everyone runs out of steam before finishing the job. With a reasonably low bar - it doesn't need to be full C90 - just enough to compile my software suite. Although I probably use most features of C90 anyway, so that doesn't buy much.


I'm not sure being similar will count as copyright infringement. The algorithm used certainly isn't copyrightable, so I'm expecting that to be near-identical yet non-infringing. If there's really only one way an author knows how to write, he shouldn't be inhibited from writing.


Ok, so that analogy may not be appropriate. In the case of the software being written for a second time, it would be to fulfill an identical task deliberately (writing a compiler or an assembler or whatever). An assembler with deliberately identical syntax etc. Unlike a painting where you're supposed to have your own ideas of a lady to draw, not attempt to reproduce someone else's lady.


It's approximately half the country is my point.


I don't doubt that the processor supports it. What I see is that it hasn't been activated by Android for my app for whatever reason, and I am unprivileged so can't argue with that decision.

No, it's definitely active and ready for you to use it. Which CPU/FPU are you telling your ancient GCC to target? The "ldfd" instruction has been obsolete for more than two decades, modern ARM CPUs don't support it.

Really? Well that changes everything.


I'm not sure. The default instructions were bad for the a.out target and I had to put -mapcs-32


I wasn't aware of that. What's the alternative 32-bit instruction? When I looked at the machine definition file I didn't notice some other instruction. And when I did research into floating point it looked like it was upwardly compatible from the period.

It only goes up to v5 though:

D:\devel\gcc\gcc\config\arm

arm.h: %{march=armv2:-D__ARM_ARCH_2__} \
arm.h: %{march=armv2a:-D__ARM_ARCH_2__} \
arm.h: %{march=armv3:-D__ARM_ARCH_3__} \
arm.h: %{march=armv3m:-D__ARM_ARCH_3M__} \
arm.h: %{march=armv4:-D__ARM_ARCH_4__} \
arm.h: %{march=armv4t:-D__ARM_ARCH_4T__} \
arm.h: %{march=armv5:-D__ARM_ARCH_5__} \
arm.h: %{march=armv5t:-D__ARM_ARCH_5T__} \
arm.h: %{march=armv5e:-D__ARM_ARCH_5E__} \
arm.h: %{march=armv5te:-D__ARM_ARCH_5TE__} \

But as I said - I thought that floating point from v5 was upwardly compatible.

I'm not sure I'm getting v5 even though.

I tried adding this:

-mcpu=xscale

But it was still ldfd.

Are you sure that is obsolete? It's a pseudo-op that gets translated into something recognized by disasm.pro

Also note that I am doing some work on gcc 3.4.6 at the moment, so that might give me more options.

I don't know if the VFP instruction set has direct equivalents for every FPA instruction.


I looked too. GCC 3.2.3 doesn't support VFP, only FPA.


I'm not sure when VFP was first introduced, but that might be the upward-compatible floating-point instruction set you found.


Yes.


It's only recognized as a generic coprocessor instruction. That's like if you fed a FSINCOS opcode into an 8086 disassembler and got "esc 0xf, bx" out of it: the disassembler knows it's a coprocessor instruction, but doesn't know whether your coprocessor supports it.


I looked at machine definition files in GCC 3.4.6 too, but unfortunately I didn't see any VFP instructions there either. I don't think VFP support was added to GCC until the 4.0 releases.