Live data from Hacker News

Building GCC 1.27 (first GCC with x86 support) (2019)

kristerw.blogspot.com

51–60 of 68 posts

Re: Building GCC 1.27 (first GCC with x86 support) (2019)

#51
post #18
post #14

Earlier quoted context omitted.

That’s because Eric Ostrom had somehow gotten us a vax 750 for some inexplicable reason (years later he told me he was astonished that nobody appreciated it) as if anybody wanted a vax. So RMS started using it for his gnu project since nobody else cared. It was just using up power in a small machine room on the 3rd (or 7th — I can’t remember) floor of tech square. Complete happenstance.

A 750 wasn't very fast back in 1987 if I remember it correctly? But a 784 was still decent?

A 750 was a nice 'personal computer' in 1987 (I ran 3 of them in that year, along with a 780 and a bunch of different microVaxen/Vaxstations) especially if you had plenty of memory (8MB was comfy, 14MB max). CPU wasn't so fast (less than 1MIP), but I/O was well engineered and well matched so it 'felt' responsive. It was reasonably fast with 1 user, not terrible up to maybe 3-4 power users and significantly more just doing email/text processing/etc. And the CPU only weighed about 100lbs (without rack & disks)!

The 784 was more capable (with caveats), but 1) only a handful were ever built (less than 10?), and 2) it was huge, both in physical size and power consumption (it's basically 4 x 11/780s with a custom interconnect cabinet). And as I understand not terribly reliable. You might be thinking of the 785, which was an improved 780, so it was still big and power hungry, but lots more were built.

Re: Building GCC 1.27 (first GCC with x86 support) (2019)

#52

Earlier quoted context omitted.

Mainstream GCC has never supported 16-bit code on x86, only 32-bit However, there is (at least one) fork which adds 16-bit code support, see https://github.com/tkchia/gcc-ia16 I don't think the GCC maintainers have ever or will ever want to support 16-bit x86, because it is so limited, and adds a lot of messy corner cases, and nowadays is really only of hobbyist/retrocomputing interest. Maybe there is some 16-bit x86…

It is kind of cool to be able to program an 8088 with C++14. :-D I have no idea what to use it for, but hey.

How many C++14 specific features will fit in 64k segments?

Re: Building GCC 1.27 (first GCC with x86 support) (2019)

#53

> the first version of GCC supporting the x86 CPU I have to say, that gives me a funny sort of feeling. The linked 0.9 tarball appears to support the Motorola 68000 and Vax, and https://gcc.gnu.org/backends.html seems to indicate that both are still supported, which is kind of beautiful (though there's a note on vax that "A hardware implementation is not currently being manufactured":P). Just... disconcerting to imag…

There's a pretty active retro community around the VAX arch, and a really decent emulator in SIMH, so the compiler still gets some love.

The 68k arch is still in production, so no reason not to support it. LLVM added 68k support in the last couple of years.

Re: Building GCC 1.27 (first GCC with x86 support) (2019)

#54
post #38
post #26

Earlier quoted context omitted.

No, but it had been lying around unused in a machine room, powered up, for a few years. RMS published the GNU manifesto in 83 or 84.

Wasn't VAX assembly very orthogonal and nice? I can understand if it was used as a compiler target, whereas x86 strikes me as harder to deal with? So if you have the space and free electricity in 1987, sure, give me a fast VAX. Not so much if you live in a student dorm, but I'm sure some have done that too.

Wasn't VAX assembly very orthogonal and nice?

This is the stuff of religious wars; and the VAX is the patron saint of the CISC school of ISA design. Large parts of the VAX ISA are very nice, and it's a lot of fun to program in assembler. There's (relatively for the time) lots of registers, and tons of addressing modes. But some of it is plain bonkers. How many variations of ADDL3 are there across all addressing modes? Dunno...thank gawd the doco is excellent. Then you get to things like INDEX and the numerous character string instructions and suddenly you got a migrane. You want BCD? Well of course you do. A CRC instruction? The customer is always right. Bit fields? Why wouldn't we? Didn't find something you like? We have the writable control store option so you can microcode your own instructions.

Re: Building GCC 1.27 (first GCC with x86 support) (2019)

#55
post #46
post #44

Instead of x86, it would be interesting to have an FPGA based PDP10 clone with 32MB of RAM, ITS patches with DNS support and, maybe, a gopher and an IRC client could be built on it. 36 bit CPU's are very interesting.

That exists, that's the TOAD2 from XKL. It apparently even runs TOPS-20. You can try one online at SDF, besides their SC-40 systems, which I think are also FPGA based. https://mastodon.sdf.org/@SDF/109824572356590874 Or you may want to get a PiDP-10, they will have an FPGA version soon to replace the RPI. https://retrocomputingforum.com/t/the-pidp-10-is-finally-don...

That's really cool. ITS with DNS and a faster CPU could do lots of 'modern' things such as maybe basic TLS and of course gopher would be a matter of spending a few months with Midas to create a client.

Re: Building GCC 1.27 (first GCC with x86 support) (2019)

#56
post #36

Earlier quoted context omitted.

x86 was originally used to refer to any intel cpu of x86 name, even in the late 80's

By which definition, this is absolutely not an "x86" compiler, since it doesn't generate code for any of those other chips. Thus my nitpick.

You are inventing the requirement that all *86 must be supported for some inexplicable reason. It is not there in any ordinary interpretation of any language including English.

If it outputs code for a single cpu from 8086 or later in that family, any single one of them, then it is "an x86 compiler".

It also doesn't matter what they would have called it at the time. When the 8086 was new, there was not yet a family of *86 model numbers, so no one would call anything an x86 anything. But that doesn't change the fact that now, when the speaker you are incorrectly trying to correct spoke, there is a set with name "x86" and the 8086 is in it.

The 8086 is an x86 cpu, and gcc 1.27 is an x86 compiler.

If you didn't think that's how those words should be interpreted, well now you are better informed, and will hopefully confuse fewer people in your future communications, and wind up in fewer arguments like this one.

Re: Building GCC 1.27 (first GCC with x86 support) (2019)

#57
post #52

Earlier quoted context omitted.

It is kind of cool to be able to program an 8088 with C++14. :-D I have no idea what to use it for, but hey.

How many C++14 specific features will fit in 64k segments?

"Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17"

https://www.youtube.com/watch?v=zBkNBP00wJE

Followed by,

"C++20 For The Commodore 64"

https://www.youtube.com/watch?v=EIKAqcLxtT0

Re: Building GCC 1.27 (first GCC with x86 support) (2019)

#58
post #25

Earlier quoted context omitted.

Thanks for the added nuance which I missed. As far as I knew, there has always been a strong association, even though not formal, between Kuyper's denomination (the Gereformeerde Kerken in Nederland (GKN)) and the university. Also ironical that within the GKN, one aspect of his theology was imposed by the synod, leading to a schism - again people fleeing from church control. (And one schism further led to the church…

> (And one schism further led to the church I grew up in.) If you don't mind me asking, which church is that? Church schisms is just one of those topics that may seem very dry to most people, but I personally find fascinating

Nederlands Gereformeerde Kerken. We actually re-merged last year with the Gereformeerde Kerken (vrijgemaakt), which were in turn a result of the first schism I described. I find the underlying emotions and personalities (usually the most important!), doctrine and to some extent also the organizational issues quite interesting.

Re: Building GCC 1.27 (first GCC with x86 support) (2019)

#59
post #52

Earlier quoted context omitted.

It is kind of cool to be able to program an 8088 with C++14. :-D I have no idea what to use it for, but hey.

How many C++14 specific features will fit in 64k segments?

Language features, many, I would suppose. Now, using some of the stuff from the standard library, could blow things up.

Re: Building GCC 1.27 (first GCC with x86 support) (2019)

#60
post #54
post #38

Earlier quoted context omitted.

Wasn't VAX assembly very orthogonal and nice? I can understand if it was used as a compiler target, whereas x86 strikes me as harder to deal with? So if you have the space and free electricity in 1987, sure, give me a fast VAX. Not so much if you live in a student dorm, but I'm sure some have done that too.

Wasn't VAX assembly very orthogonal and nice? This is the stuff of religious wars; and the VAX is the patron saint of the CISC school of ISA design. Large parts of the VAX ISA are very nice, and it's a lot of fun to program in assembler. There's (relatively for the time) lots of registers, and tons of addressing modes. But some of it is plain bonkers. How many variations of ADDL3 are there across all addressing modes…

Yeah, I think I remember seeing the sysops load the VAX CPU microcode using a floppy on the front panel (?)

I don't disagree in general. Writing a disassembler must have been a real challenge.

It's a waste of gates in the CPU. You put a lot of unnecessary combinatorical logic on the critical path, which limits the clock speed.

RISC chips remove everything that is not needed for the output of a C compiler, making the chip smaller and faster.

But from the perspective of Stallman writing a C compiler and having to generate and read lots of assembly code, I can see how the VAX assembly was easy to deal with. He could skip past a lot of stuff like BCD/CRC.

I'm not intimately familiar with 386 assembly, but my impression is that you have a lot of interdependencies and special cases? That can't be fun when writing a compiler. But at least it's not an accumulator-based CPU architecture like the 6502 or the PIC16, where everything has to be done through a single register.

Post reply on HN