Comment by PaulHoule | Hacker News Reader

Comment by PaulHoule | Hacker News Reader

Parent Full thread

Efficiency of Ada should be pretty close to C, but that strange thing Ada does where you define your own numeric types like

   type Day_type   is range    1 ..   31;

creeps me out a little, it makes me think I have to throw Hacker's Delight [1] in the trash if I want to use it but I could be wrong. It makes me think of the the deep history of computing, where there were a few straggler architectures (like the PDP-10 [2]) that didn't use the 8-bit byte were around and when Knuth wrote a set of programming books based on an instruction set that wasn't necessarily binary.

(Lately I was thinking about making a fantasy computer that could be hosted in Javascript which was going to be RISC but otherwise totally over the top, like there would be bitwise addressing like the PDP-10. First I wanted it to be 24 bit but then I figured I could pack 48 bits in a double so I might as well. It even would have a special instruction for unpacking UTF-8 characters and a video system intended for mixing latin and CJK characters. Still boils down to an 8-bit byte but like the PDP-10 it could cut out 11-bit slices or whatever you want. I was going to say screw C but then I figured out you could compile C for it)

[1] https://en.wikipedia.org/wiki/Hacker%27s_Delight

[2] https://en.wikipedia.org/wiki/PDP-10

Love that feature, along with derived types[1] and subtype predicates[2]. There's a special place in my heart partitioned for things that won't let you screw things up.

[1] https://learn.adacore.com/courses/intro-to-ada/chapters/stro...

[2] https://learn.adacore.com/courses/Ada_For_The_CPP_Java_Devel...

Alright, this is Hacker news, so I'm gonna nitpick...

> It even would have a special instruction for unpacking UTF-8 characters

From https://en.wikipedia.org/wiki/Reduced_instruction_set_comput... :

> The term "reduced" in that phrase was intended to describe the fact that the amount of work any single instruction accomplishes is reduced—at most a single data memory cycle—compared to the "complex instructions" of CISC CPUs that may require dozens of data memory cycles in order to execute a single instruction.

I don't think what you're describing is a RISC processor at all.

Whether accelerated UTF-8 decoding breaks RISC-ness is an interesting question, and not one with an obvious answer IMO.

Supposing we loaded 4 bytes into a register with a load instruction (quite RISC), we could then have a "decode UTF-8" instruction which could set two output registers: one receiving the decoded code point, and the other receiving the number of bytes consumed (1-4). That's another perfectly RISCy operation: read one input register, operate on it, update two output registers. Most RISC architectures also allow base+offset addressing at least, so you can chain this to another load using the output of that second register; worst case, you'd need to add base+offset in a dedicated instruction. No violations of RISC here.

However, you'd start running into problems with alignment. Loading 4 bytes into a register typically requires 4-byte alignment, but UTF-8 is a variable-length encoding (hence the desire to accelerate it in the first place!). Is unaligned load RISCy? Many architectures now support it, but they usually didn't start off with it. Then again, 64-bit architectures can just ignore the problem entirely, since they can load 8 bytes at a time, which will always be enough to fit an arbitrary 4-byte value at any alignment. You'd just need to shift the value in the register by the amount of the misalignment, which is another valid RISC operation.

If you wanted to sidestep the alignment issue, then an alternate solution would be to decode the UTF-8 sequence straight from memory, but that definitely feels more like CISC to me.

This doesn't strike me as that different than an enum.

Arithmetic is defined on range types. So day 30 + day 4 is 34, which if you then try to coerce into a day will throw an exception.

And... So? It seems you are saying Day_type + Integer is Integer, and Integer (in general) cannot safely be coerced into Day_type and... that’s logically correct?

`Day_type + Day_type` is also defined, and it overflows. That's like normal integers, and unlike enums.

Not only Ada?

Pascal is less esoteric and has had that forever.

My feelings about Pascal are pretty mixed.

Pedagogically oriented computer science profs circa 1980 were aghast that BASIC had become the standard for teaching young people to program. It was difficult to fit Pascal into a microcomputer then, so we were stuck with the atrocious UCSD Pascal [1] which used a virtual machine to make up for the weak instruction sets of many micros, particularly the 6502. Since the compiler ran inside the VM, compiling a small Pascal program was like compiling a large C++ program today.

Not long after that I got to use Pascal on a VAX which was not so bad, but pretty obviously not up to doing systems programming, particularly compared to C, which was starting to show up on micros such as Z-80s running CP/M and the TRS-80 Color Computer running OS-9.

Then I got a 80286 computer and I really liked Turbo Pascal because it added the (non-standard) facilities you need to do systems work, but went back to C when I went to school because it was portable to the 68k and SPARC based Sun machines we had.

[1] https://en.wikipedia.org/wiki/UCSD_Pascal

> compared to C, which was starting to show up on micros such as Z-80s running CP/M

I had some very limited access to CP/M z80 machines. Probably somewhere between 86-90. All I remember about the C compiler they had is that I had to swap 2 or 3 floppies to produce a linked executable, so it sounds similar to this UCSD Pascal.

My first real contact with Pascal was Turbo Pascal, and that ran loops around any other compiler I had access to back then...

I had a Coco with 2 floppies, I could compile C without any swapping. OS-9 was a real multitasking operating system, I could log into it with the keyboard and mouse and two serial ports at the same time (one with a UART, another with the terrible bit banger) The latter wasn't too bad with the portable DEC printing terminal I got that that was surplus at a credit agency.

UCSD Pascal was one of very few compiled languages you could get for the Apple ][ and other 6502 machines because the virtual machine was an answer to problem of code generation for that terrible instruction set with insufficient registers and addressing modes.

Reply on news.ycombinator.com