Is it a lost cause?

The open source movement grinds to a halt - or at least a drastic slowdown - but why would that happen ?

Remember -- if suddenly you have issues with gcc 4.x.x you can always go back to 4.x-1.x and set your compilation scripts to use that until you prove out the bug and fix the problem.

The good news about GCC and other open source compilers is:

1. You have a source code tree of all the modifications and versions and can revert pieces to earlier versions to see if the code generates successfully -- and then you have the pointer to the bug.

1. You can revert to a different (earlier or later) version to see if this works. You also can try another compiler (so many to chose from). Looks like Ubuntu 16.04 comes with support for 4 versons of CLANG and 5 versions of gcc.

2. gcc can generate the assembler. You can verify it if you speak x86_64 assembler (should this be amd64?)...

-----------FILE HELLO.C---------------- //C hello world example #include int main() { printf("Hello world\n"); return 0; }

-----------END OF FILE HELLO.C---------------- Generated assembler code...

hello.s

.file "hello.c" .section .rodata.str1.1,"aMS",@progbits,1 .LC0: .string "Hello world" .section .text.unlikely,"ax",@progbits .LCOLDB1: .section .text.startup,"ax",@progbits .LHOTB1: .p2align 4,,15 .globl main .type main, @function main: .LFB23: .cfi_startproc subq $8, %rsp .cfi_def_cfa_offset 16 movl $.LC0, %edi call puts xorl %eax, %eax addq $8, %rsp .cfi_def_cfa_offset 8 ret .cfi_endproc .LFE23: .size main, .-main .section .text.unlikely .LCOLDE1: .section .text.startup .LHOTE1: .ident "GCC: (Ubuntu 5.3.1-14ubuntu2.1) 5.3.1 20160413" .section .note.GNU-stack,"",@progbits

Bill

In article , jmfbahciv wrote:

Only one kind of CPU in the world. What?

Barb -- Windows runs on both Intel x86 and Arm and amd64 (x88_64) and GCC 4.3.5 still supported VAX on NetBSD and OpenBSD. IA64 is the Itanium. I think that gcc still runs on Alpha and Itanium VMS. Vax support of VMS GCC bitrotted away a while ago, I think.

I don't know if PDP11 cross compilation works anymore but I have older GCC that should work somewhere downstairs on a CDROM from the

Some of the below are cross compilation targets, I think but still it's not ONE cpu type.

Current list of supported GCC targets: | Characteristics Target | HMSLQNFICBD lqrcpbfmgiates

-----------+--------------------------- aarch64 | Q q b gia s alpha | ?? Q C q mgi e arc | B b gi arm | b ia s avr | L FI l cp g bfin | F gi c6x | S CB gi cr16 | L F C g s cris | F B c gi s epiphany | C gi s fr30 | ?? FI B pb mg s frv | ?? B b i s h8300 | FI B c g s i386 | ? Q q b ia ia64 | ? Q C qr b m i iq2000 | ??? FICB b g t lm32 | F g m32c | L FI l b g s m32r | FI b s m68k | ? cpb i mcore | ? FI pb mg s mep | F C b g t s microblaze | CB i s mips | Q CB qr ia s mmix | HM Q C q i e mn10300 | ?? c gi s moxie | F g t s msp430 | L FI l b g s nds32 | F C ia s nios2 | S C i nvptx | S Q C q mg e pa | ? Q CBD qr b i e pdp11 | L IC qrc b e rl78 | L F l g s rs6000 | Q C qr pb i rx | s s390 | ? Q qr gia e sh | Q CB qr p i sparc | Q CB qr b i spu | ? Q *C mgi stormy16 | ???L FIC D l b i tilegx | S Q C q gi e tilepro | S F C gi e v850 | ?? FI c g s vax | M? I c b i e visium | B g t s xtensa | C

I'm just an old Sysadmin but I'm sure some of the programmers here know a lot more than I do.

Bill

They ship with the source code for the GCC compiler suite.

GCC is now doing more than just C and C++. There's now a Gnu Cobol out there and a FreePascal. Much of this was built on top of some of the parts of GCC.

Bill

This real-time feat was accomplished by running a tiny real-time hypervisor under the Master Control Program, originally written for the B3500 around

And FORTRAN.

Governments want to restrict access.

/BAH

That's reexamining your assumption?!!! You are becoming annoying.

/BAH

That's something which will pop up into your regret consciousness :-(. I have quite a few regrets but most of them were out of my control. If I was prescient, I would have "stolen" DEC materials and stored them in my house.

/BAH

need

you

optimisation.

aggressive,

lot

That's a list of what has been or is supported over the years. Are there really edit trails for each one; and none have been remastered? Sounds like a headache waiting to explode.

So how is the C compiler code organized? I would have a module for each CPU type instead of conditionals. Or does the C compiler code use a default based on the system doing the build unless a /CPU switch is on the COMPILE C.* command line?

/BAH

I'm not sure I'd consider it a hypervisor in the modern sense. The pocket select routine in the application would run in control state.

For MCP/VS 2.0 (which was microkernel based), we had a separate real-time interrupt and would run the pocket select routine in a high-priority microkernel thread (called an independent runner).

By the mid 1980s, the host would download the sort criteria to the sorter and would receive batches of MICR data over a datacomm line - the host was no longer required to provide real-time responses per-item.

For the most part, x86_64 and amd64 are the same thing. There are some minor (not generally[*] application visible) differences in the privileged MSRs and the hypervisor interfaces are completely different.

Note the interesting optimization that the compiler generated below - it scanned the format string for the printf(3), noted there were no formatting parameters, and converted it to a call to the more efficient puts(3).

Yeah, I saw that. Bit naughty really.

GCC has C, C++, Objective C, Fortran, Java, Ada and Go front-ends integrated into the distribution.

Not-yet-integrated front-ends include pascal, mercury, COBOL, Modula-2, Modula-3, GHCDL, PL/1 and Unified Parallel C.

Governments are not the only organisations that desire power. Open source was too open. People misused the lack of vetting to enter and, instead of helping, hijacked the organisation for personal power.

Insecurity based on perception of personal mediocrity is conducive to selfish motivations.

You don't understand modern source control. There is a edit trail for the entire collection (that's the final C in GCC - Gnu Compiler Collection).

Remastering isn't required in modern source control systems, which allow you to recreate the project at any point in time (by date or by version).

Each compiler in the collection can be considered to be a combination of a front-end (language specific) which produces a language-independent parse tree, a global optimizer that optimizes the intermediate tree and a back-end code generator (target processor specific) that actually generates the object code based in the intermediate tree (and performs certain target specific peephole optimizations).

So, the C, COBOL, FORTRAN, et alia front-ends all generate an intermediate tree that is processed by the optimizer and then passed to the target-specific back-end. The interfaces between the passes (they're not really passes, but you can conceptually think of them that way) are standard so any front-end can generate intermediate trees that all the back-ends will be able to process and generate code for.

When you build a compiler, it can be built either native (generates code for the host OS/processor it was built with) or cross (generates code for a different target processor/OS). I use both forms daily.

And they want to promote it at the same time.

-- mrr

It is very well organised. This is one suite which compiles c, c++, fortran, cobol and maybe some others. They built an internal representation, and then massage it for optimisation and code generation.

Yes, Barb, there is a log of every edit committed to the source control system gcc has been in since, if not day one, very early.

-- mrr