On 2021-08-25 11:49 a.m., ben via cctalk wrote: > On 2021-08-25 1:25 a.m., Eric Smith via cctalk wrote: >> >> 432 GDP instructions were bit-aligned in an instruction object, and >> occupied anywhere from 6 to 344 bits. > > Did not the IBM 7030 try a similar idea. > All this work to replace a punched card. > Funny how records where simple on decimal computers > and are mess on binary ones. > >> Although there are many reasons for the failures of both the 432 and the >> P7/BiiN processor, one they had in common was that their advanced >> architectural features were especially suited to high level languages, >> such >> as Ada, and very poorly suited to low level languages, such as C. As >> everyone knows, the world chose to standardize on C. The P7, and later >> the >> i960, could run C code perfectly well, but C code couldn't easily take >> advantage of the advanced architectural capabilities of the P7/BiiN >> processor. >> > > C uses cheap tricks for speed. 8 bit bytes, 32 bit integers, taken from
That is not how C defines bytes or ints, fyi. > B. I have 21 bit CPU, with 3 7 bit bytes/word. Algol would have a > PACK/UPACK function, and be fairly portable. C on the other hand a mess. > Ok. I don't have 21 bit cpu, but I have this spare FPGA card ... > >> world chose to standardize on C. > More like the same 32 bit/ 8 bit bytes vanilla cpu, with push and pop > on the stack. Can't have near/far pointers with some intel products > so we need new standard for the non PDP/11 or VAX computers, and again > and again... > > Ben. >
