Re: FpgaC developers wanted :)

fpga_toys@xxxxxxxxx wrote:
Erik Widding wrote:
The remainder of the table can be assumed to have a value of "don't
care", in many languages this requires a first (or default) assignment
to the state of "don't care" that may or may not be overridden.

Not true in C. Assuming a don't care, would allow covering a term which
doesn't have an explict implicant, and potentially change a variable
that was remotely set. That brings us to two separate cases:

1) globals always have a default value of zero, so there is never a
don't care for this case.

2) function variables have an undefined value initially, and it's
considered poor programming practice to leave the variable unassigned
before any reference, as the value will have a nondeterminate state
(possibly it's prior state, prior stack contents, but implementation
dependent).

As such, there isn't any asserted term that can properly be a don't
care by your construction in C, as assignments imply implicants, and
lack of assignments/implicants imply retained state (no modification of
the variable).

How do you handle the case when a local variable (very local, as in
local to the block) is being used to store a partial calculation?

Many coding standards insist that a line of code not wrap (at least as
a general rule). The point of this is not all variables have a notion
of state (as in a flop), as they are created locally, assigned once and
only read once locally. I would assume there are a lot of instances
where a local variable is used for the readability of the code, rather
than with the intent of creating another stage in a pipeline. How does
FpgaC differentiate between variables that are meant to be another
stage in a pipeline (i.e. a flop) and those that are merely for
convenience (i.e. a combinatorial node)?

Many coding standards insist that global variables not be used, except
when used as semaphores or in a similarly limited way to share data
between two threads. As I understand it the few remaining places where
it is considered acceptable to use a lot of global variables is in
resource limited (i.e. 8bit micros with little ram) systems. So for
the most part I would think the "changed outside of the scope" argument
is moot. Most compilers assume that a variable can not be changed
outside of the scope unless it is declared VOLATILE. So, I don't buy
the argument as anything more than a special case.

In the usage of variables with scope no more global than the single
sequential path through the a block, is it more important to take the
strict ansi-C interpretation that anything declared is implicitly zero,
and follow the logic tree through; or is it worth understanding when
the logic has nodes that truly have a "don't care" component and
optimizing as such?

If the possibility to optimize is ignored, I fear you are creating a
tool that may have some academic interest, but not widespread practical
use.

I will be the first to admit that I have not played with FpgaC at all -
and have no intention to. But I assume there have to be pragmas to
direct the compiler to deal with pipeline and concurrency issues, as
there is no support in the language for this. Much of the use of a
sequential language for representing sequential logic has to implicitly
told to the compiler so that it can understand which variables
represent combinatorial nodes, and which represent sequential nodes.

Being only C-like and not actually ansi-C, please enlighten me why it
is important to hold on to one of the aspects of the language (implicit
zeros which is not universal across all types of variables in the
language, just in most cases) that kills efficiency when targetting
hardware, when so many other aspects have to be bastardized to make the
use of this language for this purpose even possible?

I ask, these questions because my cursiosity has been piqued - and I
obviously clearly don't understand.



Regards,
Erik.


---
Erik Widding
President
Birger Engineering, Inc.


(mail) 100 Boylston St #1070; Boston, MA 02116
(voice) 617.695.9233
(fax) 617.695.9234
(web) http://www.birger.com

.

Loading