In your RHDL you have to use .assign or .<< to do signal assignment,
annoying thing also in my code for HW CPU model.
In ruby, the "=" will assign other *object* to a *variable*, and can't
(and shouldn't) be overrided. There are no simple way to modify the
state of an *object* referenced by a *variable*. Using .assign or
overriding other operators to do this job are both ugly. I notice that
someone suggested ":=" operator which can be overrided. I dream of it
all the days :). If I have ":=", I'm sure that my CPU model will save
at least half of the current lines and the program will be much more
natural and clearer.
In short, when you use ruby to model some objects, the ability to
assign/modify the *object* state/value in simple expression way is very
useful. It provides the possibility of running ruby code *directly* to
model other worlds.
Right. But not all object states or values can be changed that way,
and there is no meaningful default operation for such a behaviour.
Thus, it makes more sense to use the appropriate #<< or #assign
mechanism.
I can't use << and other operators, for they are all meaningful in my
CPU model and have precedence problem. And I can't force anybody to
program "R0.assign(R0&R1)" for my CPU, otherwise I will be kicked to
death. I have to translate "Rx=..." to "Rx.assign ...", then eval the
latter.
The ":=" need not be supported by all classes. To use it or not, it's
the programmer's choice.
In message "Re: Do you want ":=" operator?" on 04/07/16, "Xiangyu Yang" <xiangyu.yang@gmail.com> writes:
I can't use << and other operators, for they are all meaningful in my
CPU model and have precedence problem. And I can't force anybody to
program "R0.assign(R0&R1)" for my CPU, otherwise I will be kicked to
death. I have to translate "Rx=..." to "Rx.assign ...", then eval the
latter.
I don't think I'm going to add ":=" just for cosmetic purpose. But
you can define "attribute assignment method" such as "x.foo=val".
Can you accept method call like "R.x=..." instead of "Rx := ..."?
Right. But not all object states or values can be changed that way,
and there is no meaningful default operation for such a behaviour.
Thus, it makes more sense to use the appropriate #<< or #assign
mechanism.
I can't use << and other operators, for they are all meaningful in my
CPU model and have precedence problem.
yes, usually these operators ('<<' and '>>' ) are used for shifting or
rotating registers in hardware descriptions. You can always define an
'sl' or 'shift_left' method for your classes I suppose, but '<<' and '>>'
are widely understood especially among Verilog programmers.
And I can't force anybody to
program "R0.assign(R0&R1)" for my CPU, otherwise I will be kicked to
death.
Yeah, hardware designers are a tough crowd
I have to translate "Rx=..." to "Rx.assign ...", then eval the
latter.
Wow, you're really serious about this
The ":=" need not be supported by all classes. To use it or not, it's
the programmer's choice.
I can't use << and other operators, for they are all meaningful in my
CPU model and have precedence problem. And I can't force anybody to
program "R0.assign(R0&R1)" for my CPU, otherwise I will be kicked to
death. I have to translate "Rx=..." to "Rx.assign ...", then eval the
latter.
>I can't use << and other operators, for they are all meaningful in
my
>CPU model and have precedence problem. And I can't force anybody to
>program "R0.assign(R0&R1)" for my CPU, otherwise I will be kicked to
>death. I have to translate "Rx=..." to "Rx.assign ...", then eval
the
>latter.
I don't think I'm going to add ":=" just for cosmetic purpose. But
The cosmetic is one of the most important reasons I choise ruby.
I also use ruby to prototype or verify algorithms. Sometimes it's very
handy to run a pseudo-code in ruby, but sometimes hard (same reason of
":="). This additional syntax feature will ease my life very much.
Anyway, it's personal opnion and relates strongly to the application
field. Many peopel may never want to use the feature I argue for.
you can define "attribute assignment method" such as "x.foo=val".
Can you accept method call like "R.x=..." instead of "Rx := ..."?
聽聽聽聽聽聽聽聽聽聽聽聽聽聽matz.
No, I can't. Each Rx is a RegisterClass *object* in my CPU, which hold
some states. When I code "R0=R0&R1", I only want to change 1 of the
R0's attributs and don't touch others.
路路路
In message "Re: Do you want ":=" operator?" > on 04/07/16, "Xiangyu Yang" <xiangyu.yang@gmail.com> writes:
You may wonder why I focus on program appearance so much. The key point
is productivity. I use script languages to speed my work. At the same
time I'm a project leader and want my members can all improve their
works. I had found someone access serial port by several hundred lines
in C++, while it costs only 3 or 4 lines in Tcl; and another one spend
half a day to write a hex2bin, while it's so easy in ruby. But it's
hard to force everyone to study Tcl or Ruby in deep. And normally they
only use very limited part of the features. I don't want to teach ruby
in ordor to use my cpu simulation environment. If the users can type
code just as pseudo-code of the algorithm and even don't know they are
actually programming in Ruby, it's the success of my design, and also
the language's.
Phil Tomson wrote:
In article <cd7f3e$lmt@odbk17.prod.google.com>,
>>Right. But not all object states or values can be changed that way,
>>and there is no meaningful default operation for such a behaviour.
>>Thus, it makes more sense to use the appropriate #<< or #assign
>>mechanism.
>
>>-austin
>>--
>>Austin Ziegler * halxsxtaxuxx@gxxxxxxlx.cox
>>* Alternate: ausxin@hxaloxxtxxxuex.xa
>
>I can't use << and other operators, for they are all meaningful in
my
>CPU model and have precedence problem.
yes, usually these operators ('<<' and '>>' ) are used for shifting
or
rotating registers in hardware descriptions. You can always define
an
'sl' or 'shift_left' method for your classes I suppose, but '<<' and
'>>'
are widely understood especially among Verilog programmers.
>And I can't force anybody to
>program "R0.assign(R0&R1)" for my CPU, otherwise I will be kicked to
>death.
Yeah, hardware designers are a tough crowd
>I have to translate "Rx=..." to "Rx.assign ...", then eval the
>latter.
Wow, you're really serious about this
>The ":=" need not be supported by all classes. To use it or not,
In message "Re: Do you want ":=" operator?" on 04/07/16, "Xiangyu Yang" <xiangyu.yang@gmail.com> writes:
you can define "attribute assignment method" such as "x.foo=val".
Can you accept method call like "R.x=..." instead of "Rx := ..."?
No, I can't. Each Rx is a RegisterClass *object* in my CPU, which hold
some states. When I code "R0=R0&R1", I only want to change 1 of the
R0's attributs and don't touch others.
Then how about changing R0 to R[0]?
聽聽R[0]=R[0]&R[1]
would work fine, if you can accept the appearance.
You may wonder why I focus on program appearance so much. The key point
is productivity. I use script languages to speed my work. At the same
time I'm a project leader and want my members can all improve their
works. I had found someone access serial port by several hundred lines
in C++, while it costs only 3 or 4 lines in Tcl; and another one spend
half a day to write a hex2bin, while it's so easy in ruby. But it's
hard to force everyone to study Tcl or Ruby in deep. And normally they
only use very limited part of the features. I don't want to teach ruby
in ordor to use my cpu simulation environment. If the users can type
code just as pseudo-code of the algorithm and even don't know they are
actually programming in Ruby, it's the success of my design, and also
the language's.
you can define "attribute assignment method" such as "x.foo=val".
Can you accept method call like "R.x=..." instead of "Rx := ..."?
No, I can't. Each Rx is a RegisterClass *object* in my CPU, which hold
some states. When I code "R0=R0&R1", I only want to change 1 of the
R0's attributs and don't touch others.
Then how about changing R0 to R[0]?
R[0]=R[0]&R[1]
would work fine, if you can accept the appearance.
聽聽聽聽聽聽聽聽聽聽聽聽matz.
I suspect that the problem with doing this would be that R0 and R1 are
registers (arrays of bits). He probably already uses R[0] to access bit
0 of the register
and R[1] to access bit 1 and so on. What he's doing with 'R0=R0&R1' is
logically ANDing the two registers, so that:
I suspect that the problem with doing this would be that R0 and R1 are registers (arrays of bits). He probably already uses R[0] to access bit 0 of the register and R[1] to access bit 1 and so on. What he's doing with 'R0=R0&R1' is logically ANDing the two registers, so that:
I suspect that the problem with doing this would be that R0 and R1 are registers (arrays of bits). He probably already uses R[0] to access bit 0 of the register and R[1] to access bit 1 and so on. What he's doing with 'R0=R0&R1' is logically ANDing the two registers, so that:
聽聽R0="1111"
聽聽R1="0100"
聽聽R0=R0&R1 #R0 is now "0100"
for example. and:
聽聽puts R0[0] #=> 0
But then this would become R[0][0]. Not *so* bad perhaps.
But IIRC, Matz has said he has (potentially) other things in mind
for a := operator.
