1 Jan
2019
1 Jan
'19
2:36 p.m.
On Jan 1, 2019, at 2:00 PM, ben via cctalk <cctalk
at classiccmp.org> wrote:
On 1/1/2019 8:58 AM, Carlo Pisani via cctalk wrote:
Huh? I don?t understand the 1 pass compiler statement requiring RISC. I was doing 1 pass
compilers
in the mid-to-late 70?s (well before RISC). So I?m not sure what you?re talking about.
It also depends
upon what you mean by ?1 pass?. Most compilers nowadays make only one pass over the
source but
will make multiple passes over the intermediate form before finally generating code (even
then it may
make another pass over the resulting generated code for peep-hole optimizations.
RISC is actually nice for a compiler because it?s simple and fairly regular (hard to
actually generate code
automatically for complex instructions) and RISC has a large number of registers.
However, modern
CPUs are all out-of-order execution with register renaming with ridiculous numbers of
registers (I think
current Intel Core x CPUs have 192+ registers for register renaming where the visible
number of registers
is 8). It also allows for speculative execution (following multiple paths through the
code until the data
required for the various decision points is finally available).
hi
on DTB we are designing a RISC-ish CPU, code name "Arise-v2"(1).
We are using the MIPS R2K and the RISC-V as the reference.
In the end, it will be implemented in HDL -> FPGA.
The page on DTB is related to a software emulator (written in C) for
the whole system. CPU + RAM + ROM + UART, etc. so we can test and our
ISA more comfortably.
As a second reference, I'd like to consider the first Motorola RISC:
88K, which is very elegant and neat ISA; unfortunately, I have
difficulties at finding user manuals and books about it.
If someone wants to sell me a copy, it will be appreciated!
Thanks and happy new year!
I was never a fan of RISC architecture as does not fit the standard high level language
model. Everybody wants a 1 pass compiler, thus the RISC model. If you are doing your own
RISC model, you might consider a model
that supports Effective addressing better since we have got the point
where fetching the data is taking longer than processing it.
The other thought is the pipeline seems has too high speed of a clock,
what is the use a fast clock, if you got one or two gates of logic between your clocks.
Gate and line driving speed ratios remind me of the Vacuum tube era of computing.
Deep pipelines are needed to get clock speeds up so that timing can be met. The problem
with deep
pipelines is that when any sort of exception (interrupts, etc) happen, there?s a lot of
state that gets flushed
and then restarted when the exception handling completes.
Pipelines (especially if they?re not fixed depth for all operations) means that simple
operations (those that
require a minimum number of pipeline stages) can be completed quickly where as complex
operations
that require either a lot of logic or time to complete can be broken up in to multiple
stages. This allows
a higher clock rate and allows for the simple operations to be completed more quickly than
if there was
a very shallow pipeline.
TTFN - Guy