I'm trying to do some interesting orbit mechanics, I've found some related code in Fortan and I'm going through line by line moving it to Visual Basic. I can't understand what this is though:
IF(ABS(EPW-TEMP2) .LE. E6A) GO TO 140
It's not a variable. I figure E6 might be 10^6 but what's the 'A' mean?
Thanks!
When I google that line of code, I end up with some "Spacetrack Report No.3" with the fortran code listing. And E6A is defined as 1.E-6 in the routine DRIVER (Page. 73)
DATA DE2RA,E6A,PI,PIO2,QO,SO,TOTHRD,TWOPI,X3PIO2,XJ2,XJ3,
1 XJ4,XKE,XKMPER,XMNPDA,AE/.174532925E-1,1.E-6,
2 3.14159265,1.57079633,120.0,78.0,.66666667,
4 6.2831853,4.71238898,1.082616E-3,-.253881E-5,
5 -1.65597E-6,.743669161E-1,6378.135,1440.,1.
I see this code has already been converted to Java and C, perhaps you should use those as reference.
Related
I'm writing a program for my circuit analysis class that calculates the total resistance in parallel resistors given a list of the Ohms of each resistor. My code is as follows:
DelVar ⌊RL
Input "R List: ",⌊RL
0→RT
For(X,1,dim(⌊RL))
RT+(⌊RL(X))→RT
End
RT→Ans
Disp RT
The code looks fine to me. The little square in there is actually a ^-1 in the calculator. But I get a syntax error when I run this code, which for whatever reason points me to the line 0→RT.
Figured it out, apparently most models of the TI-84 don't allow more than 1 letter variable names for number vars. Also yes I noticed a couple mistakes with the calculation in my code, and have fixed it:
DelVar ⌊RL
Input "R List: ",⌊RL
0→R
For(X,1,dim(⌊RL))
R+(⌊RL(X))→R
End
Disp R
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.
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.
I wish to make use of a subroutine in a DLL for my research. The dll is provided to me as a blackbox and can be used in a leading FE software.
I executed the following code for the dll
dumpbin /EXPORTS UDSM_HPS.dll > UDSM_HPS.exports
and ended up with the following subroutine
2 0 00020D50 _getmodelcount#4
4 1 00020D60 _getmodelname#12
6 2 00020E50 _getparamcount#8
8 3 00020E80 _getparamname#16
10 4 00021AE0 _getparamunit#16
12 5 00001010 _user_mod#124
1 6 00020D50 getmodelcount
3 7 00020D60 getmodelname
5 8 00020E50 getparamcount
7 9 00020E80 getparamname
9 A 00021AE0 getparamunit
11 B 00001010 user_mod
My interest lies in the 'user_mod' subroutine. I created a .lib file from the .def file, by adding 'EXPORTS' in the beginning of the file and isolating the subroutine names, using the following code
lib /def:UDSM_HPS.def /out:UDSM_HPS.lib
and attached the .lib file to the 'Resourse Files' to my Visual Studio 2013, while placing a copy of my .dll to my 'Debug' folder.
No surprises here, the 'user_mod' subroutine is not seen by the compiler.
Now My question, am I missing something, or is there a differnt way of utilising the subroutine from the dll?
The dll is written in FORTRAN too, and I have written a simple piece of FE code in FORTRAN to run this subroutine.
Long story short: Any assistance is figuring out how to utilise a FORTRAN dll in FORTRAN program is much appreciated.
Edit 1:
I am using the Intel Fortran compiler - Intel(R) Visual Fortran Compiler XE 15.0.6.285 [IA-32]. I had tried compiling the same piece of code in Intel(R) Fortran Compiler 10.1.021 [IA-32], but in vain.
The subroutine I intend to call is
call user_mod(IDTask, iMod, IsUndr, iStep, iTer,&
iEl, Int, X, Y, Z, Time0, dTime, Props, Sig0, Swp0, StVar0,&
dEps, D, BulkW, Sig, Swp, StVar, ipl, nStat, NonSym, iStrsDep,&
iTimeDep, iTang, iAbort)
To clarify my rather vague sentence of 'not seen by the compiler', I meant this error
Error 1 error LNK2019: unresolved external symbol USER_MOD referenced in function PLAXIS_DLL_INTF interface_files.obj
Edit 2:
Thanks for the all the help.
Adding
!DEC$ ATTRIBUTES STDCALL,REFERENCE :: USER_MOD
was all that was needed to get my code going. Code is behaving like how it should now.
Thanks for providing the error message - that is the key. It isn't the compiler that can't see user_mod, it's the linker. Note that the error message refers to USER_MOD, but your dump of the symbols says user_mod. Case matters!
It is also important that the routine you're calling has the STDCALL calling mechanism. This is not the Intel Fortran default, and getting this wrong leads to stack corruption.
The solution is to add the line:
!DEC$ ATTRIBUTES STDCALL,REFERENCE :: USER_MOD
to the routine calling USER_MOD - in with the declarations. This tells Intel Fortran that USERMOD is a STDCALL routine, and downcases the routine name. Also make sure that you are passing the correct number and type of arguments when you call USER_MOD. If you get this wrong, you'll get link errors. Last, I am guessing about the use of REFERENCE here, but I will assume it is correct since I don't know how USER_MOD was built. At least this will get you past the link error.
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.