On 2014-06-13, David Brown <david.brown@hesbynett.no> wrote:> On 13/06/14 01:15, Hans-Bernhard Br?ker wrote: >> On 13.06.2014 00:20, Don Y wrote: >> >>> Write it in the same language that you are compiling -- that way you >>> *know* you have THAT tool available wherever you happen to maintain >>> the codebase (instead of having to have *two* tools). >> >> Except when you don't, which would tend to apply to people in this >> newsgroup more than any other group. >> >> Just because you're already writing embedded software in C doesn't mean >> you'll also have a "native" C compiler for your desktop OS anywhere near >> you. >> > > If you are using Linux then you will always have a native C compiler > handy.Nope. Plenty of distros don't install a C compiler by default.> Of course, you will also have Python, which is a much nicer language > for this sort of scripting (it's quick to learn enough Python to > write such scripts).But the _do_ install python by default. -- Grant
filling remaining array elements with fixed value
Started by ●June 12, 2014
Reply by ●June 12, 20142014-06-12
Reply by ●June 12, 20142014-06-12
Hi Grant, On 6/12/2014 6:19 PM, Grant Edwards wrote:> On 2014-06-12, Don Y<this@is.not.me.com> wrote: >> On 6/12/2014 3:02 PM, Randy Yates wrote: >>> Grant Edwards<invalid@invalid.invalid> writes: >>>> On 2014-06-12, Randy Yates<yates@digitalsignallabs.com> wrote: >>>> >>>>> I go along with the others who suggested that you write some C/C++ code >>>>> to generate this code. I've done that many times and it works well. >>>> >>>> I find it's usually _way_ faster to write a Python program to generate >>>> such things, but YMMV. >>> >>> Yeah, sure, python, perl, common lisp, scheme, erlang, c, c++, etc. - >>> pick yer' poison. >> >> Write it in the same language that you are compiling -- that way you >> *know* you have THAT tool available wherever you happen to maintain >> the codebase (instead of having to have *two* tools). > > I don't understand. If I'm writing in C for the '430, how does that > guarantee I have C for the development host?It doesn't guarantee that you have it for the host. But, neither does it guarantee that you have python, perl, sh, etc. for the host! What it *does* guarantee is that *you* will know how to write C for that host (more or less)! It doesn't guarantee that you will be able to write a perl script *if* you happened to have perl available to you on *that* host (e.g., none of my windows hosts have perl installed). [I'll ignore the pedantic case where you can often use the target C compiler to generate the required output -- albeit in a round-about manner -- as an object for the target... that you manually misappropriate back into your development environment!]
Reply by ●June 12, 20142014-06-12
Grant Edwards <invalid@invalid.invalid> writes:> On 2014-06-13, David Brown <david.brown@hesbynett.no> wrote: >> On 13/06/14 01:15, Hans-Bernhard Br?ker wrote: >>> On 13.06.2014 00:20, Don Y wrote: >>> >>>> Write it in the same language that you are compiling -- that way you >>>> *know* you have THAT tool available wherever you happen to maintain >>>> the codebase (instead of having to have *two* tools). >>> >>> Except when you don't, which would tend to apply to people in this >>> newsgroup more than any other group. >>> >>> Just because you're already writing embedded software in C doesn't mean >>> you'll also have a "native" C compiler for your desktop OS anywhere near >>> you. >>> >> >> If you are using Linux then you will always have a native C compiler >> handy. > > Nope. Plenty of distros don't install a C compiler by default. > >> Of course, you will also have Python, which is a much nicer language >> for this sort of scripting (it's quick to learn enough Python to >> write such scripts). > > But the _do_ install python by default.In this day of package managers, it's practically irrelevent. If it isn't installed by default, and you can type three words - "yum install gcc" - you're done. -- Randy Yates Digital Signal Labs http://www.digitalsignallabs.com
Reply by ●June 13, 20142014-06-13
On 14-06-13 03:09 , Mark Curry wrote:> In article <lnd9ll$nja$1@dont-email.me>,> ...thread drift...> We currently have a setup to do nightly builds of all our code. We've > seriously considered, but haven't pulled the trigger yet, on also setting > up a build on a virtual machine. This build on the virtual machine > wouldn't happen as often, but the virtual machine snapshot would theoretically > capture "everything". The virtual machine snapshot could then be > checked into revision control. > > Sounds like overkill, but it some industries, being able to faithfuly rebuild > something 5, 10, 15+ years down the line could be useful...How sure are you that your virtual machine snapshot, taken in 2014 on your current PC and hypervisor, will run on your brand-new PC in the year 2029? As I understand them, what are called "virtual machines" on PCs only virtualize as little of the machine as is necessary to support multiple OS's on the same hardware, but are not full emulations of the PC processor and I/O. I have not seen any promises from hypervisor vendors to support 15-year-old VM snapshots on future PC architectures, which may be quite different. This question is of interest to me because I am working on projects with maintenance foreseen until the 2040's. Some people have suggested virtual machines as the solution for keeping the development tools operational so long, but I am doubtful. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .
Reply by ●June 13, 20142014-06-13
Hi Niklas, On 6/12/2014 9:05 PM, Niklas Holsti wrote:> On 14-06-13 03:09 , Mark Curry wrote:>> We currently have a setup to do nightly builds of all our code. We've >> seriously considered, but haven't pulled the trigger yet, on also setting >> up a build on a virtual machine. This build on the virtual machine >> wouldn't happen as often, but the virtual machine snapshot would theoretically >> capture "everything". The virtual machine snapshot could then be >> checked into revision control. >> >> Sounds like overkill, but it some industries, being able to faithfuly rebuild >> something 5, 10, 15+ years down the line could be useful... > > How sure are you that your virtual machine snapshot, taken in 2014 on > your current PC and hypervisor, will run on your brand-new PC in the > year 2029?"Sure"? <grin> How sure are you that the host OS, VM vendor, tool vendor, silicon vendor, etc. will be *around* at that time?> As I understand them, what are called "virtual machines" on PCs only > virtualize as little of the machine as is necessary to support multiple > OS's on the same hardware, but are not full emulations of the PC > processor and I/O. I have not seen any promises from hypervisor vendors > to support 15-year-old VM snapshots on future PC architectures, which > may be quite different. > > This question is of interest to me because I am working on projects with > maintenance foreseen until the 2040's. Some people have suggested > virtual machines as the solution for keeping the development tools > operational so long, but I am doubtful.This is worthy of an entirely new thread -- and, some significant professional investment! Long term support is tedious, at best. Try finding someone who can write 6502 code, today (do-able as the military relies on this processor; repeat the exercise with 2650 and you'll get far sparser results!). What media do you plan on storing the sources (and tools)? Will you be able to *read* that media 25 years hence? (when was the last time you saw a 5" floppy? 8"?? 8" hard sectored???) What efforts have you made to document all of these requirements/dependencies/formats? Will people even *know* what they need to have available in order to perform that maintenance? Etc.
Reply by ●June 13, 20142014-06-13
On 12-Jun-14 5:24 PM, Wouter van Ooijen wrote:>> #define TEN_FFS 0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF >> const unsigned char my_array[8]={ >> 0xA, 0xB, 0xC, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF >> TEN_FFS, TEN_FFS, TEN_FFS, TEN_FFS, TEN_FFS, >> TEN_FFS, TEN_FFS, TEN_FFS, TEN_FFS, TEN_FFS >> }; >> #undefine TEN_FFS > > I misread, you want 1000, not 100, but that requires only two more lines ;) >Novel approach! Interesting
Reply by ●June 13, 20142014-06-13
On 6/12/2014 3:24 AM, Wouter van Ooijen wrote:>> #define TEN_FFS 0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF >> const unsigned char my_array[8]={ >> 0xA, 0xB, 0xC, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF >> TEN_FFS, TEN_FFS, TEN_FFS, TEN_FFS, TEN_FFS, >> TEN_FFS, TEN_FFS, TEN_FFS, TEN_FFS, TEN_FFS >> }; >> #undefine TEN_FFS > > I misread, you want 1000, not 100, but that requires only two more lines ;) >
Reply by ●June 13, 20142014-06-13
On 6/12/2014 3:24 AM, Wouter van Ooijen wrote:>> #define TEN_FFS 0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF >> const unsigned char my_array[8]={ >> 0xA, 0xB, 0xC, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF >> TEN_FFS, TEN_FFS, TEN_FFS, TEN_FFS, TEN_FFS, >> TEN_FFS, TEN_FFS, TEN_FFS, TEN_FFS, TEN_FFS >> }; >> #undefine TEN_FFS > > I misread, you want 1000, not 100, but that requires only two more lines ;) >Don't you mean 200 more lines !!
Reply by ●June 13, 20142014-06-13
On 6/12/2014 11:20 PM, hamilton wrote:> On 6/12/2014 3:24 AM, Wouter van Ooijen wrote: >>> #define TEN_FFS 0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF >>> const unsigned char my_array[8]={ >>> 0xA, 0xB, 0xC, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF >>> TEN_FFS, TEN_FFS, TEN_FFS, TEN_FFS, TEN_FFS, >>> TEN_FFS, TEN_FFS, TEN_FFS, TEN_FFS, TEN_FFS >>> }; >>> #undefine TEN_FFS >> >> I misread, you want 1000, not 100, but that requires only two more >> lines ;) >> > Don't you mean 200 more lines !!sorry, 20 lines
Reply by ●June 13, 20142014-06-13
On Friday, 13 June 2014 15:21:56 UTC+10, hamilton wrote:> On 6/12/2014 11:20 PM, hamilton wrote: > > > On 6/12/2014 3:24 AM, Wouter van Ooijen wrote: > > >>> #define TEN_FFS 0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF > > >>> const unsigned char my_array[8]={ > > >>> 0xA, 0xB, 0xC, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF > > >>> TEN_FFS, TEN_FFS, TEN_FFS, TEN_FFS, TEN_FFS, > > >>> TEN_FFS, TEN_FFS, TEN_FFS, TEN_FFS, TEN_FFS > > >>> }; > > >>> #undefine TEN_FFS > > >> > > >> I misread, you want 1000, not 100, but that requires only two more > > >> lines ;) > > >> > > > Don't you mean 200 more lines !! > > sorry, 20 linesIt's been a few years but couldn't you write: #define TEN_FFS 0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF #define HUN_FFS TEN_FFS,TEN_FFS,TEN_FFS,TEN_FFS,TEN_FFS,TEN_FFS,TEN_FFS,\ TEN_FFS,TEN_FFS,TEN_FFS #define THOU_FFS HUN_FFS,HUN_FFS,HUN_FFS,HUN_FFS,HUN_FFS,HUN_FFS,HUN_FFS,\ HUN_FFS,HUN_FFS,HUN_FFS Chris
