You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be great to support vamp-ir's [] abstraction
// k-bit xor and
def xor[k] x y -> z { ... }
def and[k] x y -> z { ... }
where [k] means the xor function takes a constant integer to compile with. For Alucard, this would ideally be inferred, however we can explicitly declare it with the constant field in the circuit signature.
Further I think as we wish to write more complex circuits a compile-time will allow us to serve a circuit that is paramatarized over a common lisp value, that we must supply when extracting.
This can be very useful for testing certain behaviors when extracting or for grabbing round data from disk and supplying them before generating out the circuit.
For example
(deftypepoint ()
(x int)
(y int))
(deftypenested ()
(plane point)
(time point))
(defcircuit root-test ((public root int)
(constant field))
(= (bit-or field (*3 root) 214)
0))
(defcircuit record-test ((public root int)
(private planer nested)
(constant bit-size)
(compile-time hash-round-data)
(output nested))
;; apply is a normal CL function
(apply#'and
(bit-xor bit-size root (x (plane planer)))
;; mapcar is also a CL function, the rest are all alucard;; functions/values!
(mapcar (lambda (constant-from-disk)
(root-test constant-from-disk root))
hash-round-data)))
Note :: at the bottom of this issue we discuss alternative syntax to compile-time.
could be an example of using constant to setup a root-test. And a compile-timehash-round-data to read hash round constants off disk to plant them in the circuit, which we then require to hold true by the and that is called upon the given equations.
Compilation Technique
For constant not much has to change, simply the vamp-ir layer needs to be notified of this, and we need to make sure that we can't place an intermediate value in the place where a constant value is taken.
Some shuffling will have to be done if constant are not the first argument due to how vamp-ir holds it's arguments, but that is less of an issue.
For compile-time a bit more will have to change. As our storage mechanism will have to be either a constraint as it is now, or a CL lambda which evaluates to a constraint. This means that we have to be careful during extraction, and extract with only the compile-time arguments given.
This makes the given syntax misleading as we have to supply only the compile-time values before extracting.
However once that issue is solved, all that has to be done is to make sure each circuit with compile-time arguments are handed them before running the pipeline
Syntax Challanges
This makes the proposed syntax misleading, as what we are doing is akin to
which would take no infrastructure change on my side to support (In fact this pattern works currently, but sadly redefines what the circuit is on every generate call...).
I'm unsure of how to effectively communicate this with the current diesgn, maybe something along the lines of a let over the cirucit would be better?
Idea
It would be great to support
vamp-ir
's [] abstractionwhere
[k]
means the xor function takes a constant integer to compile with. For Alucard, this would ideally be inferred, however we can explicitly declare it with theconstant
field in the circuit signature.Further I think as we wish to write more complex circuits a
compile-time
will allow us to serve a circuit that is paramatarized over a common lisp value, that we must supply when extracting.This can be very useful for testing certain behaviors when extracting or for grabbing round data from disk and supplying them before generating out the circuit.
For example
Note :: at the bottom of this issue we discuss alternative syntax to
compile-time
.could be an example of using
constant
to setup a root-test. And acompile-time
hash-round-data
to read hash round constants off disk to plant them in the circuit, which we then require to hold true by theand
that is called upon the given equations.Compilation Technique
For
constant
not much has to change, simply the vamp-ir layer needs to be notified of this, and we need to make sure that we can't place an intermediate value in the place where a constant value is taken.Some shuffling will have to be done if constant are not the first argument due to how vamp-ir holds it's arguments, but that is less of an issue.
For
compile-time
a bit more will have to change. As our storage mechanism will have to be either aconstraint
as it is now, or a CLlambda
which evaluates to aconstraint
. This means that we have to be careful during extraction, and extract with only thecompile-time
arguments given.This makes the given syntax misleading as we have to supply only the
compile-time
values before extracting.However once that issue is solved, all that has to be done is to make sure each circuit with compile-time arguments are handed them before running the pipeline
Syntax Challanges
This makes the proposed syntax misleading, as what we are doing is akin to
which would take no infrastructure change on my side to support (In fact this pattern works currently, but sadly redefines what the circuit is on every generate call...).
I'm unsure of how to effectively communicate this with the current diesgn, maybe something along the lines of a let over the cirucit would be better?
The text was updated successfully, but these errors were encountered: