implementing components of a computer processor using .hdl and the Hardware Simulator (nand2tetris) - hdl

I'm having trouble getting my .hdl files to loads in the HardwareSimulator. So far I have implemented FullAdder.hdl and Add16.hdl.
The error message I'm recieving is
line 22, zab has no source pin
Here is the relevant code for the Add16:
CHIP Add16 {
IN x[16], y[16];
OUT out[16];
PARTS:
HalfAdder(x=x[0],y=y[0],sum=out[0],carry=c);
FullAdder(x=x[1],y=y[1],c=c,sum=out[1],carry=d);
FullAdder(x=x[2],y=y[2],c=d,sum=out[2],carry=e);
FullAdder(x=x[3],y=y[3],c=e,sum=out[3],carry=f);
FullAdder(x=x[4],y=y[4],c=f,sum=out[4],carry=g);
FullAdder(x=x[5],y=y[5],c=g,sum=out[5],carry=h);
FullAdder(x=x[6],y=y[6],c=h,sum=out[6],carry=i);
FullAdder(x=x[7],y=y[7],c=i,sum=out[7],carry=j);
FullAdder(x=x[8],y=y[8],c=j,sum=out[8],carry=k);
FullAdder(x=x[9],y=y[9],c=k,sum=out[9],carry=l);
FullAdder(x=x[10],y=y[10],c=l,sum=out[10],carry=m);
FullAdder(x=x[11],y=y[11],c=m,sum=out[11],carry=n);
FullAdder(x=x[12],y=y[12],c=n,sum=out[12],carry=o);
FullAdder(x=x[13],y=y[13],c=o,sum=out[13],carry=p);
FullAdder(x=x[14],y=y[14],c=p,sum=out[14],carry=q);
FullAdder(x=x[15],y=y[15],c=q,sum=out[15],carry=drop);
}
I'm strugginling to find the error since I'm pretty sure I've implemented this chip in exactly the same way in the past and it worked fine.
As for the full adder, it's the same error message but for line 16.
I'll provide the relevant code for this part also:
CHIP FullAdder {
IN x, y, z; // 1-bit inputs
OUT sum, // Right bit of x + y + z
carry; // Left bit of x + y + z
PARTS:
HalfAdder(x=x,y=y,sum=xy,carry=zxy);
HalfAdder(x=z,y=xy,sum=sum,carry=s);
Or(x=zab,y=s,out=carry);
}
I can't wrap my mind around the error referring to line 16. That's way after the terminating bracket in FullAdder.
I've browsed the internet and as far as I can tell my implementation is perfectly correct. Any advice from anyone who are proficient in the Computer Processors area? This would definitely be useful for anyone else who are running into the same/similar problems.
Thanks
edit: According to this link Logic Gates my implementation looks more or less exactly the same. Could it be a faulty HardwareSim at my end? Although I doubt that since I've used it in the past and it was recommended to me by my University.

The problem is in the x input to your Or gate in the FullAdder. You are referring to a signal (pin) "zab" but no such signal is defined.
In future, please remember to post the entire files. It is hard to help you diagnose an error in line 16 when it is difficult to tell what line that actually is.

Related

Weird behavior of the input command in Scilab

I want my students to program a little game with Scilab like this one :
a=ceil(100*rand())
disp("I think of a number between 1 and 100. Which one ?")
guess=0
while(guess<>a) do
guess= input("Guess :")
if (a>guess) then
disp("+")
elseif (a<guess) then
disp("-")
end
end
disp("You got it")
But there are some weird behavior with the first inputs and the lasts. Just after the first input, sometimes I don't have an answer (but sometimes I do), I am asked "Guess" again, but this time with a usual prompt --> on the console. I can put anything, it doesn't seem to matter for the program. But the program is not over though, just after it returns to the expected behavior.
At the end, after the "You got it", there seems to be some inputs around. I got one or two prompts before I got the --> again.
Here is what the console may look like :
Guess :
50
Guess :
--> 50
Guess :
50
+
Guess :
75
-
Guess :
I can't figure out why Scilab react like this.
I've experienced that a lot, and this is a known bug in input() of Scilab 6.0.0:
http://bugzilla.scilab.org/show_bug.cgi?id=15069
http://bugzilla.scilab.org/show_bug.cgi?id=14376
http://bugzilla.scilab.org/show_bug.cgi?id=14424
The first link also presents a workaround, but I wouldn't say it is suitable for students. As #Desire couldn't reproduce that error, I recommend that you downgrade you Scilab to version 5.5.1, and also tell your students to do it too.

Error in HEVC enconde of 16 bit depth : " enable RExt__HIGH_BIT_DEPTH_SUPPORT"

I have an problem, when i enconde the imagem with 16 bit depth i obtain one error, the error is:
"enable RExt__HIGH_BIT_DEPTH_SUPPORT";
I use the InternalBitDepth = 16 , i need use this.
I read what i need changed in TypeDef.h the next line :
#ifndef RExt__HIGH_BIT_DEPTH_SUPPORT
#define RExt__HIGH_BIT_DEPTH_SUPPORT 0 ///< 0 (default) use data type definitions for 8-10 bit video, 1 = use larger data types to allow for up to 16 bit video
I change to #define RExt__HIGH_BIT_DEPTH_SUPPORT 1 ///, and i run the makefile, but the error remained.
Whats happen?
thank you in advance
Are you sure that HM supports the bit depth of 16?
I am not sure about my claim; but I think every time I hear from someone about "higher bit depth in HM", they usually talk about 10 or at most 12 bit depth.
As I said, I am not sure at all. Maybe it supports!
If you'll find the answer, please share it with us.
Good luck
Go to the main directory.
Open CMakeList.txt.
Find the line setting HIGH_BITDEPTH.
Change OFF to ON to enable HIGH_BITDEPTH.
In the building directory, delete CMakeCache.txt.
cmake again to rebuild to project.
Fix the warnings of shifting 32bit integers (change 1 << into 1ll <<).
Done.

Creating robust real-time monitors for variables

We can create a real-time monitor for a variable like this:
CreatePalette#Panel#Row[{"x = ", Dynamic[x]}]
(This is more interesting and useful if x happens to be something like $Assumptions. It's so easy to set a value and then forget about it.)
Unfortunately this stops working if the kernel is re-launched (Quit[], then evaluate something). The palette won't show changes in the value of x any more.
Is there a way to do this so it keeps working even across kernel sessions? I find myself restarting the kernel quite often. (If the resulting palette causes the kernel to be automatically started after Quit that's fine.)
Update: As mentioned in the comments, it turns out that the palette ceases working only if we quit by evaluating Quit[]. When using Evaluation -> Quit Kernel -> Local, it will keep working.
Link to same question on MathGroup.
I can only guess, because on my Ubuntu here the situations seems buggy. The trick with the Quit from the menu like Leonid suggested did not work here. Another one is: on a fresh Mathematica session with only one notebook open:
Dynamic[x]
x = 1
Dynamic[x]
x = 2
gives as expected
2
1
2
2
Typing in the next line Quit, evaluating and typing then x=3 updates only the first of the Dynamic[x].
Nevertheless, have you checked the command
Internal`GetTrackedSymbols[]
This gives not only the tracked symbols but additionally some kind of ID where the dynamic content belongs. If you can find out, what exactly these numbers are and investigate in the other functions you find in the Internal context, you may be able to add your palette Dynamic-content manually after restarting the kernel.
I thought I had something like that with
Internal`SetValueTrackExtra
but I'm currently not able to reproduce the behavior.
#halirutan's answer jarred my memory...
Have you ever come across: Experimental/ref/ValueFunction? (documentation address)
Although the documentation contains no examples, the 'more information' section provides the following tidbit:
The assignment ValueFunction[symb] = f specifies that whenever
symb gets a new value val, the expression f[symb,val] should be
evaluated.

Circumventing R's `Error in if (nbins > .Machine$integer.max)`

This is a saga which began with the problem of how to do survey weighting. Now that I appear to be doing that correctly, I have hit a bit of a wall (see previous post for details on the import process and where the strata variable came from):
> require(foreign)
> ipums <- read.dta('/path/to/data.dta')
> require(survey)
> ipums.design <- svydesign(id=~serial, strata=~strata, data=ipums, weights=perwt)
Error in if (nbins > .Machine$integer.max) stop("attempt to make a table with >= 2^31 elements") :
missing value where TRUE/FALSE needed
In addition: Warning messages:
1: In pd * (as.integer(cat) - 1L) : NAs produced by integer overflow
2: In pd * nl : NAs produced by integer overflow
> traceback()
9: tabulate(bin, pd)
8: as.vector(data)
7: array(tabulate(bin, pd), dims, dimnames = dn)
6: table(ids[, 1], strata[, 1])
5: inherits(x, "data.frame")
4: is.data.frame(x)
3: rowSums(table(ids[, 1], strata[, 1]) > 0)
2: svydesign.default(id = ~serial, weights = ~perwt, strata = ~strata,
data = ipums)
1: svydesign(id = ~serial, weights = ~perwt, strata = ~strata, data = ipums)
This error seems to come from the tabulate function, which I hoped would be straightforward enough to circumvent, first by changing .Machine$integer.max
> .Machine$integer.max <- 2^40
and when that didn't work the whole source code of tabulate:
> tabulate <- function(bin, nbins = max(1L, bin, na.rm=TRUE))
{
if(!is.numeric(bin) && !is.factor(bin))
stop("'bin' must be numeric or a factor")
#if (nbins > .Machine$integer.max)
if (nbins > 2^40) #replacement line
stop("attempt to make a table with >= 2^31 elements")
.C("R_tabulate",
as.integer(bin),
as.integer(length(bin)),
as.integer(nbins),
ans = integer(nbins),
NAOK = TRUE,
PACKAGE="base")$ans
}
Neither circumvented the problem. Apparently this is one reason why the ff package was created, but what worries me is the extent to which this is a problem I cannot avoid in R. This post seems to indicate that even if I were to use a package that would avoid this problem, I would only be able to access 2^31 elements at a time. My hope was to use sql (either sqlite or postgresql) to get around the memory problems, but I'm afraid I'll spend a while getting that to work, only to run into the same fundamental limit.
Attempting to switch back to Stata doesn't solve the problem either. Again see the previous post for how I use svyset, but the calculation I would like to run causes Stata to hang:
svy: mean age, over(strata)
Whether throwing more memory at it will solve the problem I don't know. I run R on my desktop which has 16 gigs, and I use Stata through a Windows server, currently setting memory allocation to 2000MB, but I could theoretically experiment with increasing that.
So in sum:
Is this a hard limit in R?
Would sql solve my R problems?
If I split it up into many separate files would that fix it (a lot of work...)?
Would throwing a lot of memory at Stata do it?
Am I seriously barking up the wrong tree somehow?
Yes, R uses 32-bit indexes for vectors so they can contain no more than 2^31-1 entries and you are trying to create something with 2^40. There is talk of introducing 64-bit indexes but that will be some way off before appearing in R. Vectors have the stated hard limit and that is it as far as base R is concerned.
I am unfamiliar with the details of what you are doing to offer any further advice on the other parts of your Q.
Why do you want to work with the full data set? Wouldn't a smaller sample that can fit in to the restrictions R places on you be just as useful? You could use SQL to store all the data and query it from R to return a random subset of more appropriate size.
Since this question was asked some time ago, I'd like to point that my answer here uses the version 3.3 of the survey package.
If you check the code of svydesign, you can see that the function that causes all the problem is within a check step that looks whether you should set the nest parameter to TRUE or not. This step can be disabled setting the option check.strata=FALSE.
Of course, you shouldn't disable a check step unless you know what you are doing. In this case, you should be able to decide yourself whether you need to set the nest option to TRUE or FALSE. nest should be set to TRUE when the same PSU (cluster) id is recycled in different strata.
Concretely for the IPUMS dataset, since you are using the serial variable for cluster identification and serial is unique for each household in a given sample, you may want to set nest to FALSE.
So, your survey design line would be:
ipums.design <- svydesign(id=~serial, strata=~strata, data=ipums, weights=perwt, check.strata=FALSE, nest=FALSE)
Extra advice: even after circumventing this problem you will find that the code is pretty slow unless you remap strata to a range from 1 to length(unique(ipums$strata)):
ipums$strata <- match(ipums$strata,unique(ipums$strata))
Both #Gavin and #Martin deserve credit for this answer, or at least leading me in the right direction. I'm mostly answering it separately to make it easier to read.
In the order I asked:
Yes 2^31 is a hard limit in R, though it seems to matter what type it is (which is a bit strange given it is the length of the vector, rather than the amount of memory (which I have plenty of) which is the stated problem. Do not convert strata or id variables to factors, that will just fix their length and nullify the effects of subsetting (which is the way to get around this problem).
sql could probably help, provided I learn how to use it correctly. I did the following test:
library(multicore) # make svy fast!
ri.ny <- subset(ipums, statefips_num %in% c(36, 44))
ri.ny.design <- svydesign(id=~serial, weights=~perwt, strata=~strata, data=ri.ny)
svyby(~incwage, ~strata, ri.ny.design, svymean, data=ri.ny, na.rm=TRUE, multicore=TRUE)
ri <- subset(ri.ny, statefips_num==44)
ri.design <- svydesign(id=~serial, weights=~perwt, strata=~strata, data=ri)
ri.mean <- svymean(~incwage, ri.design, data=ri, na.rm=TRUE)
ny <- subset(ri.ny, statefips_num==36)
ny.design <- svydesign(id=~serial, weights=~perwt, strata=~strata, data=ny)
ny.mean <- svymean(~incwage, ny.design, data=ny, na.rm=TRUE, multicore=TRUE)
And found the means to be the same, which seems like a reasonable test.
So: in theory, provided I can split up the calculation by either using plyr or sql, the results should still be fine.
See 2.
Throwing a lot of memory at Stata definitely helps, but now I'm running into annoying formatting issues. I seem to be able to perform most of the calculation I want (much quicker and with more stability as well) but I can't figure out how to get it into the form I want. Will probably ask a separate question on this. I think the short version here is that for big survey data, Stata is much better out of the box.
In many ways yes. Trying to do analysis with data this big is not something I should have taken on lightly, and I'm far from figuring it out even now. I was using the svydesign function correctly, but I didn't really know what's going on. I have a (very slightly) better grasp now, and it's heartening to know I was generally correct about how to solve the problem. #Gavin's general suggestion of trying out small data with external results to compare to is invaluable, something I should have started ages ago. Many thanks to both #Gavin and #Martin.

Quick divisibility check in ZX81 BASIC

Since many of the Project Euler problems require you to do a divisibility check for quite a number of times, I've been trying to figure out the fastest way to perform this task in ZX81 BASIC.
So far I've compared (N/D) to INT(N/D) to check, whether N is dividable by D or not.
I have been thinking about doing the test in Z80 machine code, I haven't yet figured out how to use the variables in the BASIC in the machine code.
How can it be achieved?
You can do this very fast in machine code by subtracting repeatedly. Basically you have a procedure like:
set accumulator to N
subtract D
if carry flag is set then it is not divisible
if zero flag is set then it is divisible
otherwise repeat subtraction until one of the above occurs
The 8 bit version would be something like:
DIVISIBLE_TEST:
LD B,10
LD A,100
DIVISIBLE_TEST_LOOP:
SUB B
JR C, $END_DIVISIBLE_TEST
JR Z, $END_DIVISIBLE_TEST
JR $DIVISIBLE_TEST_LOOP
END_DIVISIBLE_TEST:
LD B,A
LD C,0
RET
Now, you can call from basic using USR. What USR returns is whatever's in the BC register pair, so you would probably want to do something like:
REM poke the memory addresses with the operands to load the registers
POKE X+1, D
POKE X+3, N
LET r = USR X
IF r = 0 THEN GOTO isdivisible
IF r <> 0 THEN GOTO isnotdivisible
This is an introduction I wrote to Z80 which should help you figure this out. This will explain the flags if you're not familiar with them.
There's a load more links to good Z80 stuff from the main site although it is Spectrum rather than ZX81 focused.
A 16 bit version would be quite similar but using register pair operations. If you need to go beyond 16 bits it would get a bit more convoluted.
How you load this is up to you - but the traditional method is using DATA statements and POKEs. You may prefer to have an assembler figure out the machine code for you though!
Your existing solution may be good enough. Only replace it with something faster if you find it to be a bottleneck in profiling.
(Said with a straight face, of course.)
And anyway, on the ZX81 you can just switch to FAST mode.
Don't know if RANDOMIZE USR is available in ZX81 but I think it can be used to call routines in assembly. To pass arguments you might need to use POKE to set some fixed memory locations before executing RANDOMIZE USR.
I remember to find a list of routines implemented in the ROM to support the ZX Basic. I'm sure there are a few to perform floating operation.
An alternative to floating point is to use fixed point math. It's a lot faster in these kind of situations where there is no math coprocessor.
You also might find more information in Sinclair User issues. They published some articles related to programming in the ZX Spectrum
You should place the values in some pre-known memory locations, first. Then use the same locations from within Z80 assembler. There is no parameter passing between the two.
This is based on what I (still) remember of ZX Spectrum 48. Good luck, but you might consider upgrading your hw. ;/
The problem with Z80 machine code is that it has no floating point ops (and no integer divide or multiply, for that matter). Implementing your own FP library in Z80 assembler is not trivial. Of course, you can use the built-in BASIC routines, but then you may as well just stick with BASIC.