I need an int128 (and/or int256).
Is there a library or way in which I can use that in Delphi?
Note that I do not want to muck around with strings and such, support as close as possible to int64 would be ideal.
There's BigInteger, but this calls a dll to do its work, which is not acceptable.
I remember there being another library for big numbers, but I cannot remember the name...
OK, found it at: http://sourceforge.net/projects/bigint-dl/
BigInt is the Delphi library providing operations with extremely large integer numbers, known as multi-precision arithmetics. Our primary goal is to achieve maximum performance of calculations.
The sourcecode is nicely documented in Chinese :-(
It uses mostly x86 32bit assembly (no MMX etc, which is a pity).
This is an open source unit that I have used in the past for math with 'unlimited' sized integers:
http://www.bvbcode.com/code/b1uxniwl-1626766
Would that be what you were looking for?
Ps
I am on my phone now. If this is helpful I will improve the formatting later.
Related
I'm working on a so-called cartridge, for the geo-location based WheriGo (http://wherigo.com) game. The architecture that is used for these cartridges is 32-bit and big endian. However, my luac will create chunks that are 64-bit and little endian.
While there is an online compilation service for WheriGo, I'd rather be able to produce the proper binary format for myself. Especially, because there are things I'd rather keep a bit obscured in a stripped chunk, loaded by loadstring(), rather than having the full debug information available.
So my question is this: How hard would it be to generate a lua tool chain, that generates byte code for a different architecture, than the one it is running under?
If the floating point representation of both machines is compatible, then this should be just modifications to ldump.c and lundump.c
Care taken to ensure types E.g. long are same size. I have done this for integer lua on x86,x64
You could always run a 32-bit big-endian machine as VM, e.g. Aurélien’s prebuilt images for Debian/mips (notes). It’ll be slow but work and can be automated easily. (Do a dist-upgrade to at least wheezy from squeeze, then get latest Lua.)
I've run VMs like that often enough… it's slow, but I think of it as batch processing: I start a job (apt or compile), then look at it occasionally (or: the next day) to see whether it finished. Most of the time, this works out pretty well; some things of course do not work right in emulation (e.g. due to emulator bugs or differences), but to get a big-endian 32-bit Lua, this might work).
Suggested reading: lua bytecode portability and middle-endian doubles on ARM (both on the lua mailing list) – since PocketPC machines are mostly ARM, you might run into that. Best to check the actual Wherigo cartridges to see what settings they use…
The gist of these postings is: endianness, sizeof(int), sizeof(size_t), sizeof(Instruction), sizeof(lua_Number), and type of lua_Number must be the same for the bytecode to be compatible across architectures (says Luiz Henrique de Figueiredo), and middle-endian floats (both single and double) do exist in the wild (steve donovan and Dimiter 'malkia' Stanev).
Do tell if you do it – I'm interested because I'm a geocacher myself (though need to figure out how to play cartridges, no player for my platforms).
For the purposes of binary / source code verification, i'd like to be able to make two compiles on the same computer 2 weeks apart and have the binaries be identical and thus pass some checksum test.
So far I've found that most likely the timestamp will be written by the compiler into the binary. I can work around this by doing the compare on the dumpbin /rawdata results per this msdn article.
http://support.microsoft.com/kb/164151
However the dumpbin results still differ in a about a dozen places and the difference still appears to be some kind of timestamp (changing from A1 73 to C4 76) for example.
I assume this is the timestamp that the delphi compiler is putting into the code/data sections but i can't find where this is happening or how to turn it off. Fiddling with the various compiler/linker options has not changed this behavior.
Any help would be greatly appreciated.
We researched this question a few years ago, and as I recall the answer was simply that the people at Borland/Codegear/Embarcadero do not subscribe to the notion that the compiler should produce exactly the same output given exactly the same input (given that the current date-time is not acceptable to consider as input).
This is disappointing, but given that Delphi is upmteen major versions old, it probably will not change.
Based on your comment in the question, I think you are searching for the answer to this question:
How can I verify that a certain binary is created by a certain set of source files
One way is to have an automated built process that:
Inserts a unique verififcation tag in the source code (might be as simple as a GUID string or something else in an include file)
Compiles the binaries using that verification tag
Packs the resulting binary and source code in a delivery directory tree
You must make sure that your sourcecode actually uses that verification tag (for instance by showing in an about box, or something similar).
I use FinalBuilder to automate build processes like this.
--jeroen
Unfortunately I haven't heard of any answer to this problem.
It's not just timestamps but there are places where a few bytes of random garbage out of memory ends up in the result.
I've been searching for some information regarding microcontroller programming but the info I find is either way over my head or doesn't appear to exist. I'm looking for something easier to digest! I'm relatively new to programming and come from an SQL DBA background and decided that it would be quicker for me to learn some programming fundamentals and then teach myself Delphi than it would to get some changes implemented through my company's insane design change note system!
After a couple of years of Delphi programming I can cope with writing database applications without too much bother and I want to be able to move on a level.
We use PIC microcontrollers on our PCBs; mainly the PIC18F family. The software on the PICS is written in C but there are parameters values that are written to by a Delphi application that interface with the PIC using an ActiveX control.
Basically, SQL Database holds parameter info, Delphi client app retrieves those values, passes them to the ActiveX controll which does all the low level stuff on the PIC. For example the internal EEPROM will have a map and within any particular address a value will be stored to switch something on or off or hold an integer value etc.
I've gotten hold of an MPLAB kit which has an ICD2 device that can read and write values to the internal EEPROM and I understand how to change these hexadecimal values using MPLAB software.
My hope isn't to learn embedded microcontroller programming; rather that I can write a Delphi app that will do something similar to MPLAB software. E.g read and write values to certain memory addresses within the EEPROM.
I'd be very gratefull if anyone can point me in the right direction of any libraries or components that may already exist for bridging this gap between simple Delphi form application and writing low level PIC EEPROM. I doubt such any easy interface exists but I thought I'd ask. To summarise I want to be able to have a simple form app, with some edit boxes that the user types in or selects from dropdown boxes, parameter values, to click on a button and to assign those parameter values to specific EEPROM memory addresses. Thank you for reading and any comments would be gratefully received.
Regards
KD
I'm a big fan of MikroElectronika and have used their Pascal tools for pic16 series MCU with great success (touch screen interfaces, ZigBee, ...).
http://www.mikroe.com/
Updated 2015 Answer:
Why not a Raspberry Pi with FreePascal and Lazarus? The boards cost from $5 to $25 US, as of this date, and the development tools are free.
Original 2012 Answer:
If you like to use Pascal, you might find Free Pascal useful on small embedded systems, but the minimum I believe you will find it can compile on is a Linux-based ARM embedded system. The fact that you use pascal on both sides is very unlikely to help you accomplish anything major.
If you want to go all the way down the the smallest PIC microcontrollers, you'll find that it's almost always a variant of C that you'll be using. Frankly, at that level, the differences aren't that much. If you can write Pascal, you can learn enough C in a day, to use with microcontrollers.
Don't be scared to use the native language that most microcontrollers support. My personal favorites are the Rabbit microcontrollers, formerly from Z-World, now from digi -- I think I paid about $100 US for the first board and development toolkit.
Interfacing such an application with delphi is pretty easy, usually these days, I would interface using TCP/IP over either wired Ethernet, or wireless (Wifi). But if you really want to you could use RS-232 or RS-485 serial links. (RS-485 has the advantage that you can wire it up to 5 miles long.) If I was using a serial link, I'd probably implement something like Modbus on both sides, if I just wanted to send some numeric data back and forth, and if I was doing something text-oriented, I think I'd write a mini HTTP web server on the embedded controller, and most boards these days come with enough HTTP server demos to make that drop-dead easy.
Delphi outputs Win32 and Win64 native applications you can write software that can interact with certain devices if the PCB has serial comunication or I2C you can write software that in Delphi that it will interact with the physical device.
But if you want to programm the devices yourself , write software that will run on this devices you can't do it in Delphi. I suggest you buy an Arduino it's an excellent envoirment for beginners in microcontroller programming.
If you have the source code of your pic microcontroller then you can implement the code in C to read from Serial, USB or some other interface available in your hardware and write it to the eeprom. This way its easy to write the app in any high level language like delphi, c++, etc.
Or you can write your PIC application using the mikropascal compiler from mikroeletronika that its very good and I've been using for a long time, but as you can see you will have to implement some mecanism to read from the interface and write to your eeprom as I've mentioned before.
This compiler comes with a lote of librarys to work with many devices. You should take a look on it, its not free but the price is low and in their site you can find samples and sample boards to test it.
One option, if you want a simple interface to write to the PIC EEPROM, is to use the ICD command line utility. Unfortunately it is not available for the ICD2, but the PICkit 2 and 3 (which are cheap), ICD3, and RealICE have command line utilities that give you the ability to write to the EEPROM (google pk2cmd). In Delphi, you could just wrap a very simple set of command line calls to pk2cmd.
I'm working with a team for a bigger application with Delphi 2007. It use a bigger legacy framework to access the data. Both the app and framework use String as datatype for strings. I have started to modify the code in framework to support Delphi 2009 strings, see my previous questions about this.
I see 2 alternatives now:
Alt 1 - Continue to use string as before. This is probably the cleanest solution as the framework will then supports Unicode. But the code in framework must be modified a lot to make this working. This require in depth understanding of the internal algorithms in framework. It is also a bigger chance to introduce new bugs.
Alt 2 - Replace String with AnsiString and Char with AnsiChar. This is propably a much easier solution and also how I start to modify the code (but then I start thinking and ask this question...). The negative side of this is no support for Unicode. Unicode support is not a requirement as it worked before but is nice to have. It could also be useful in the future. Another problem is that the application must send Ansistring variables as parameters in the methods for the framework instead of String as before. There are thousands of calls to change...
So I don't know right now. Both options require a lot of work, but Alt 1 is probably more risky and time consuming. What I want from this forum is feedback and comments as I guess I am not the first who have this problem.
EDIT
Another issue is the memory footprint. I wrote a quick test that allocate an array of one million strings. Each string was filled with 26 chars from A to Z.
With Delphi 2007 it took 40.011.600 bytes and the time was 4:15 minutes.
With Delphi 2009 it took 72.015.580 bytes and the time was 4:45 minutes.
The memory consumption was measured with GetHeapStatus.TotalAllocated.
I don't think we can afford to have the strings allocate twice as much memory.
It is not unusual to have 500 MB in memory consumption for each client now. I guess much of this are as strings. Propably we try to use AnsiString as much as possible.
Regards
Either stay with the old version of Delphi, or go all the way. You'll have to sooner and later anyway.
Note that the "replace everything with ansistring" scheme is also not entirely foolproof, specially if you touch streams and your fileformats need to stay the same. There are no explicite TStringlists,tstringstreams etc with ansistring anymore.
The same probably goes for Datasnap, Indy and other frameworks.
You can try to use this trick for certain string intensive parts at first, to avoid changing too much code directly. E.g. I had an own XML library, which I patched to remain mostly ansistring. The library was only used sideways, and unicode was of no importance to it.
Start with "alt 2", then gradually add unicode support to your framework, then move over to Unicode.
Rationale: you want a stable app; switching over to Delphi 2009+ will eventually require you to really support Unicode.
Edit: 20100125
While doing "alt 2" watch the Delphi compiler hints warnings.
The situation that Andreas describes will generate such hints and warnings.
I have explained this in my CodeRage 4 session about Unicode and other encodings.
The above link points to a page where you can view the replay of that session.
If you still have questions, just drop them here.
--jeroen
We evaluated the transition 2007 -> 2009 a year ago and tried a a smaller project (200k lines). The result was that everywhere where you do not use "fancy" things like pointers, set of char etc the porting is really not that difficult . Especially the GUI units we're ported within a day or so. This is equivalent to opt1.
The library units with low level routines, access to measurement systems etc etc was a whole different story. Here we choose to translate string -> ansistring, char -> ansichar etc etc. Porting these units is a pain to get correct and the customer won't pay for the transition. Hence opt2 for those units.
This mixed method gave us best of both worlds but we will keep some larger projects at Delphi 2007 and probably only port when a 64 bit version of the compiler will come out.
It'll be more work, but I'd really recommend that you upgrade to Unicode strings, because that's the native string type of the VCL and so all your controls will be dealing with Unicode strings anyway. Trying to convert everything back and forth will cause you all sorts of hassles.
I'm currently working on upgrading a product for the Chinese market. The target is a ARMTDMI7 with a QVGA display. Most resources I've located on the net are targeted at desktop or web programming rather than embedded devices.
Can anyone suggest some tools and
resources that might be useful?
What are the best techniques for
extracting literal strings and
communicating with translators?
I suggest looking at EasyGUI but that depends on what graphics controller you use.
EasyGUI is a tool that simplifies design of user interfaces and comes with complete source code and driver for a varity of display controllers.
For localization you can use EasyTranslate that gives the translater a graphical representation of the interface. This lets the translator see how the translated texts fit on the screen.
EasyGUI is available with unicode support aswell as right to left script.
Freetype might be good for rendering fonts.
www.freetype.org
There are many ARM microcontroller forums which will help you find what you're looking for.
Atmel has a line of ARM7 processors, and they are pretty friendly to those who make a hobby out of this, so there's a lot of information on this processor. It won't be the same, but generally the tools and libraries can be used across the ARM line so you might find some help here - you'll want to focus on the AT91SAM7 series.
If you have more specific questions, you will probably get some reasonable response here.
-Adam
It sounds like you need to upgrade an existing codebase to make it support multiple languages.
If so, the fact that this is on a microcontroller shouldn't be an issue - I'd drop that fromt he title and focus on the language you're using (c?) and ask how to convert your program for internationalisation.
This is a problem many people have solved on a variety of platforms, and the fact this you're on a microcontroller doesn't mean that the same tools and such don't apply - the relevant factor is the language you're using
-Adam