Extremely CISC instructions
toby at telegraphics.com.au
Wed Aug 25 10:58:05 CDT 2021
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,
>> 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
>> i960, could run C code perfectly well, but C code couldn't easily take
>> advantage of the advanced architectural capabilities of the P7/BiiN
> 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...
More information about the cctech