gallier2

D has them both

.init is not necessarily 0. For int it is, but for float it's NaN. For char it's 255 and for an enum, it's whatever you have decided it is. enum thing { first = -1, second, etc. } This way, a variable of type thing has -1 as init value.

What makes the choice of < > for template parameter bad appears when someone tries to nest templates.

     a<b<arg>> 

a(template params)(runtime params) at declaration a!(template params)(runtime params) at invocation with the type deduction and parenthesis omission making often even disappear completely the template syntax.

thank you

I just wrote a somewhat bigger program in D and I mostly used UFCS chains for the toString() overrides to have better debug outputs. There are also some idiomatic forms that are frequent like conversion bar = foo.to!int is much more readable than bar = to!int(foo)

D such a fantastic language.

Apple /// was 2MHz and it was a disaster.

It was not just a bandwidth issue. I remember my first encounter with the Internet was on a HP workstation in Germany connected to South-Africa with telnet. The connection went over a Datex-P (X25) 2400 Baud line. The issue with X25 nets was that it was expensive. The monthly rent was around 500 DM and each packet sent also had to been paid a few cents. You would really try to optimize the use of the line and interactive rsh or telnet trafic was definitely not ideal.

There also SDC which is an experimental D compiler not using DMD code. I don't know how complete it is but it is actively updated.

NEC V20/V30 not that much but 80186 and all their specialized embedded variants from Intel (80186EA/EB/EC) and AMD (Am186EM) were extremely appreciated as it allowed to use normal MS-DOS compilers and software.

Am186EM we loved that one. 100 pin PQFP with unmultiplexed bus, CMOS up to 40Mhz, including UART, SPI etc.

Motorola's embedded cpu's had strange numbers that would make it difficult to recognize to which cpu family it belonged. 68705 were 6800 derived, 68302 were 68000 derived. As for the 6809 it l ooks like that there were no embedded derivatives of it. 68HC16 seems to be a 16 bit extended 6800 using a similar technic as 65816 to extend the 6502.

In the list of applications of the 6502 architecture there is one big missing entry. Good old phone line modems using Rockwell chipsets (Hayes modem) that went up to 56Kbit/s. The central controller of the Rockwell chipset was an embedded MPU based on 65C02 kernel that were clocked to up to 75MHz (that's the fasted I had seen). The fact is relatively unknown as NDA with Rockwell were extremely tight.

There are also some very questionable statements in the articlle like saying that 6502 instructions only need one cycle. It's 2 to 7 in reality. Over the years the comparison between 6502 vs Z80 tend to show that you have to clock the Z80 at about twice the frequency of the 6502 to get the same performance. 8088 having a slight edge over the Z80 it is clear that a 5 MHz will be quite faster than a 1 MHz 6502 (C64 was even under 1MHz as the VIC chip would steal some cycles every 8th display line)

and

    ubyte - 8 bits
    ushort - 16 bits
    uint - 32 bits
    ulong - 64 bits
    ucent - 128 bits
    
    float - 32 bits
    double - 64 bits
    real - maximum precision hardware allows (80 bits on x87).

it has defined the type for very long: it's cent and ucent. It hasn't implemented it completely though, but named and defined it is already forever.

For bool it's even worse.

Yes, and that was exactly my point (yes, I wrote that SO answer). The indirect addressing mode that were introduced with 68020 are insane. Most people don't know them, as they didn't exist in 68000/68010/68008 and most compilers did not implement them as they were slower to use than using simpler composed addressings.

It is interesting to see what Motorola cut from the instruction set when they defined the Coldfire subset (for those who don't know, the coldfire family of CPU used the same instruction set as 68000 but radically simplified, the indirect addressing methods, the BCD mode, a lot of RMW instructions, etc. were removed. The first coldfire after 68060 which was limited to 75Mhz, ran at up to 300MHz).

Philips was a big proponent of MSX.

Take an Atari ST and you can see what a m68k PC could have been. Its operating system GEMDOS was a derivative of CP/M with comparable features of MS_DOS. The syscall even use the same numbers (trap #1 calls to GEMDOS map 1:1 on int 21H MS-DOS calls).

This said, several hardware PC-emulators on the Atari did exactly the thing that article describes. PC-Speed added a NEC V30 that was soldered on the 68000 and could takeover the bus and the emulation only consisted on simulating the peripherals. It worked like a charm and thanks to the generous memory of the ST could even do some things better than real PC's (for example the 640K limit was in reality a 736K limit). Later versions used 286 and even 386sx cpu's.

People often forget that 'ab' or '1ert' multi-char immediate are allowed in C. They are almost unusable as they are highly un-portable (because of endianess issues between the front-end and the back-end).

D from Walter Bright took that problem head on and solved it quite nicely.

https://digitalmars.com/articles/C-biggest-mistake.html https://dlang.org/articles/d-array-article.html

The calculators they have today in high-school here (France) use Python as programming interface (TI-83 Premium)

He appeared also several times in TV in his late years and it was always a delight. He was more a painter as a scientist in his late years but always funny and very nice.

Compound literals are anonymous variables, i.e. like variables except that there is no label visible in the C program. If you look at the assembly you'll see that they are declared exactly like a variable except with a compiler generated internal label.

Cool. Two of the tricks shown are from my contribution in stackoverflow.

Tell me you haven't read the paper without saying you haven't read it.

That's the issue with C++ metaprogramming. It's so unwieldy and complex that the benefits are difficult to see and the occasions to be worthwhile limited. When the language has better (i.e. simpler) facilities for meta-programming like D, it will open big venues where it makes sense to use it. It is like programming object oriented in C, it is possible to do but so unwieldy and requiring discipline and verbose boiler plate that there's rarely an occasion where it would be interesting to use. While it is much easier to do in C++ or D or Java (etc.) as they provide the abstractions that makes it useable. C++'s meta-programming facilities are not good enough.

<i>D will always evaluate normal "if's" at runtime even if they are comptime-known, it will not do this automatically for you.</i>

WRONG. if in a CTFE function works without problems. static if has nothing to do with CTFE. static if is conceptually a beefed up proper #ifdef/#endif.

The biggest issue D has is all the FUD and misconceptions that are propagated about it.

The AGC (Apollo Guidance Computer). This means we won't go to the moon anytime soon ;-)

That really undersells the `static if considered paper` which has got to be the most offensive standards paper I've read.

Indeed. Never read something stinking so much of sour grapes from NIH-suffering old farts.

Loved my V30 in my Atari ST. The fun part was that it was faster than the 68000 on bus access (3 cycles instead of 4) which allowed with some special drivers to accelerate even operations under TOS.