* Win CE target @ 1998-09-20 0:00 William A Whitaker 1998-09-20 0:00 ` Tucker Taft ` (3 more replies) 0 siblings, 4 replies; 40+ messages in thread From: William A Whitaker @ 1998-09-20 0:00 UTC (permalink / raw) Is there such a thing as an Ada 95 Win CE target. Does it make sense? I have never seen, touched or smelled a Win CE so I have no idea if it is possible or desirable. Whitaker ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Win CE target 1998-09-20 0:00 Win CE target William A Whitaker @ 1998-09-20 0:00 ` Tucker Taft 1998-09-21 0:00 ` dennison 1998-09-20 0:00 ` Win CE target dewarr ` (2 subsequent siblings) 3 siblings, 1 reply; 40+ messages in thread From: Tucker Taft @ 1998-09-20 0:00 UTC (permalink / raw) William A Whitaker (whitaker@erols.com) wrote: : Is there such a thing as an Ada 95 Win CE target. Does it make sense? : I have never seen, touched or smelled a Win CE so I have no idea if it : is possible or desirable. We have an Ada 95 compiler that generates efficient, human-readable ANSI C as an intermediate language. Given sufficient interest, this could be integrated with any ANSI C development system for "Wince" to produce an Ada 95 capability. : Whitaker -- -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Burlington, MA USA An AverStar Company ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Win CE target 1998-09-20 0:00 ` Tucker Taft @ 1998-09-21 0:00 ` dennison 1998-09-21 0:00 ` dewarr 0 siblings, 1 reply; 40+ messages in thread From: dennison @ 1998-09-21 0:00 UTC (permalink / raw) In article <EzLBxq.40n.0.-s@inmet.camb.inmet.com>, stt@houdini.camb.inmet.com (Tucker Taft) wrote: > We have an Ada 95 compiler that generates efficient, human-readable > ANSI C as an intermediate language. Given sufficient interest, this > could be integrated with any ANSI C development system for "Wince" > to produce an Ada 95 capability. Is this the legendary "Ada to C" converter that everyone is always asking about? :-) -- T.E.D. -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Win CE target 1998-09-21 0:00 ` dennison @ 1998-09-21 0:00 ` dewarr 1998-09-28 0:00 ` Ada --> C Translation, was: " Stefan Helfert 0 siblings, 1 reply; 40+ messages in thread From: dewarr @ 1998-09-21 0:00 UTC (permalink / raw) In article <6u65h0$f1b$1@nnrp1.dejanews.com>, dennison@telepath.com wrote: > In article <EzLBxq.40n.0.-s@inmet.camb.inmet.com>, > stt@houdini.camb.inmet.com (Tucker Taft) wrote: > > > We have an Ada 95 compiler that generates efficient, human-readable > > ANSI C as an intermediate language. Given sufficient interest, this > > could be integrated with any ANSI C development system for "Wince" > > to produce an Ada 95 capability. > > Is this the legendary "Ada to C" converter that everyone is always asking > about? :-) Well of course the issue is the word "readable" in Tuck's message (some people can read things more easily than others, after all some people think the whole of the Ada RM is quite readable :-) Compiling Ada by translating into C is nothing new, at least two vendors have followed this route before. Whether IM has somehow managed to succeed where the others failed in producing readable code remains to be seen. Some of the trouble areas in compiling into C are 1. Arithmetic overflow checks, especially in complex expressions, which have to be broken down into steps or written in prefix notation. 2. Nested procedures, and particularly nested procedures with complex local declarations. 3. Subunits (hard to do anything other than create a huge source in which the subunits are substituted). 4. Exceptions Note here I am talking about readability, rather than efficiency, although all the above are also efficiency issues. Of course if you write simple minded Ada that uses only features that translate into C, then the two vendors compilers that I have talked about in the past have worked fine. Note that the list above is a small one, there are many other problems. It is interesting in the case of GNAT and GCC, that of course it was possible for us to translate GNAT into a form that can be processed by the backend, but we preferred not to because the transformations were awkward and would have intefered with optimizations in some cases. So we enhanced the backend for example by adding self describing types to map Ada's variant records directly. And remember we were working not with C, but with GNU C, which solves some of these problems Actually if I was trying to write a translator like this, I would certainly consider Ada to GNU C, which would be much easier. However, that would not meet all needs (e.g. the requirement as for the SHARC of interfacing to the vendors proprietary C compiler). I will say for the record, that, according to MY definition of readability, it is not possible to translate Ada 95 into readable C in all cases. -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada --> C Translation, was: Win CE target 1998-09-21 0:00 ` dewarr @ 1998-09-28 0:00 ` Stefan Helfert 1998-09-29 0:00 ` Tucker Taft 1998-09-29 0:00 ` Robert A Duff 0 siblings, 2 replies; 40+ messages in thread From: Stefan Helfert @ 1998-09-28 0:00 UTC (permalink / raw) dewarr@my-dejanews.com wrote: [...] > Some of the trouble areas in compiling into C are > > 1. Arithmetic overflow checks, especially in complex > expressions, which have to be broken down into steps > or written in prefix notation. > > 2. Nested procedures, and particularly nested procedures > with complex local declarations. > > 3. Subunits (hard to do anything other than create a huge > source in which the subunits are substituted). > > 4. Exceptions > [...] > I will say for the record, that, according to MY definition > of readability, it is not possible to translate Ada 95 into > readable C in all cases. Clearly this is a statement that you cannot argue with. But I am tempted to add that the C preprocessor features clearly help to add readability to a certain degree. One of my projects some time ago was a ML2C-translator, where we wanted to preserve "style" (not only readability). Now ML covers, as you may know, most of the language features that Ada sports (especially those mentioned above) and adds more (famous: garbage collection). And ML as a functional language is relying on a different programming paradigm. The C preprocessor did really help a lot: E.g., you can implement exceptions with setjmp/longjmp and hide this before the users' eyes, or hide the interface to the garbage collector/memory management. Stefan Helfert ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada --> C Translation, was: Win CE target 1998-09-28 0:00 ` Ada --> C Translation, was: " Stefan Helfert @ 1998-09-29 0:00 ` Tucker Taft 1998-09-30 0:00 ` dewarr 1998-09-29 0:00 ` Robert A Duff 1 sibling, 1 reply; 40+ messages in thread From: Tucker Taft @ 1998-09-29 0:00 UTC (permalink / raw) dewarr@my-dejanews.com wrote: [...] > Some of the trouble areas in compiling into C are > > 1. Arithmetic overflow checks, especially in complex > expressions, which have to be broken down into steps > or written in prefix notation. > > 2. Nested procedures, and particularly nested procedures > with complex local declarations. > > 3. Subunits (hard to do anything other than create a huge > source in which the subunits are substituted). > > 4. Exceptions > [...] > I will say for the record, that, according to MY definition > of readability, it is not possible to translate Ada 95 into > readable C in all cases. Stefan Helfert (helfert@galileo.mpi-hd.mpg.de) wrote: : Clearly this is a statement that you cannot argue with. Nevertheless, it is possible to "compile" all of Ada 95 to C, which can be useful for using Ada on a target lacking a "full-up" Ada compiler, and it is possible to "translate" much of Ada 95 to reasonably readable C, which can ease certain kinds of reuse, and can be used to satisfy certain clients' arbitrary requirements for C. For what that's worth... As an example of reasonably readable C, I have appended a translation of a simple priority-heap package, where the automated translator did its best to preserve comments, Ada names, etc. in the generated C. Note that constraint checks have been suppressed in this translation, to avoid offending the sensibilities of C programmers ;-). The original Ada is appended at the end. : Stefan Helfert -- -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Burlington, MA USA An AverStar Company ----------- prio_heap_pkg.spc.h --------- #ifndef __prio_heap_pkg_spc_h__ #define __prio_heap_pkg_spc_h__ #include "standard.ada.h" typedef uint8 Prio_heap_pkg_Prioritynumber; extern void Prio_heap_pkg_Add_prio(Prio_heap_pkg_Prioritynumber Prio_To_Add); /* | Add new prio to prio heap */ extern void Prio_heap_pkg_Remove_top_prio(); /* | Remove top priority from prio heap */ extern void Prio_heap_pkg_Print_prio_heap(); /* | Print all priorities in priority heap, */ /*| in priority order. */ /** *| Overview *| This package maintains a "binary heap" of priorities *| allowing fast access to the highest priority in the heap. **/ #endif /* prio_heap_pkg.spc.h */ ----------- prio_heap_pkg.bdy.h --------- #ifndef __prio_heap_pkg_bdy_h__ #define __prio_heap_pkg_bdy_h__ #include "standard.ada.h" #include "prio_heap_pkg.spc.h" /** *| Overview *| This package maintains a "binary heap" of priorities *| allowing fast access to the highest priority in the heap. **/ #define Prio_heap_pkg__Min_prio ((Prio_heap_pkg_Prioritynumber)(0)) /*| Lowest priority supported. */ #define Prio_heap_pkg__Num_prio ((Universal_integer)(255 - 0+1)) /*| Number of priorities supported */ typedef uint16 Prio_heap_pkg__Prio_heap_count; /** *| type for count of items in prio heap *| One extra so may always assume have 2 or 0 children (see *| Remove_Prio below). **/ typedef Prio_heap_pkg__Prio_heap_count Prio_heap_pkg__Prio_heap_index; /*| subtype for index into prio heap */ extern uint8 Prio_heap_pkg__Prio_heap[257]; /** *| List of priorities which might have non-empty task queue. *| This list is organized as a "binary heap" where *| Prio_Heap(n/2) > Prio_Heap(n) for n in 2..Num_In_Prio_Heap. *| Initialize to Min_Prio to simplify Remove_Prio algorithm. **/ extern Prio_heap_pkg__Prio_heap_count Prio_heap_pkg__Num_in_prio_heap; /*| Count of items in prio heap */ extern Boolean Prio_heap_pkg__In_prio_heap[256]; /*| Indication for each priority whether in prio heap */ /*| Highest priority which might have non-empty queue */ extern void Prio_heap_pkg__Print_prio_list (Prio_heap_pkg__Prio_heap_index Parent); /* | Print all priorities in heap */ /*| in priority order, starting at given slot */ #endif /* prio_heap_pkg.bdy.h */ ----------- prio_heap_pkg.bdy.c --------- #include "standard.h" #include "prio_heap_pkg.bdy.h" /** *| Overview *| This package maintains a "binary heap" of priorities *| allowing fast access to the highest priority in the heap. **/ uint8 Prio_heap_pkg__Prio_heap[257] = {(uint8 )(int32 ) Prio_heap_pkg__Min_prio, (uint8 )(int32 )Prio_heap_pkg__Min_prio, ( uint8 )(int32 )Prio_heap_pkg__Min_prio, ... [... elided lots of repeats ...] Prio_heap_pkg__Min_prio, (uint8 )(int32 )Prio_heap_pkg__Min_prio}; /** *| List of priorities which might have non-empty task queue. *| This list is organized as a "binary heap" where *| Prio_Heap(n/2) > Prio_Heap(n) for n in 2..Num_In_Prio_Heap. *| Initialize to Min_Prio to simplify Remove_Prio algorithm. **/ Prio_heap_pkg__Prio_heap_count Prio_heap_pkg__Num_in_prio_heap = {0}; /*| Count of items in prio heap */ Boolean Prio_heap_pkg__In_prio_heap[256] = {False, False, False, False, False, False, False, False, False, False, False, False, False, False, [... elided lots of repeats ...] False, False, False, False, False, False, False, False, False, False, False, False}; /*| Indication for each priority whether in prio heap */ /*| Highest priority which might have non-empty queue */ void Prio_heap_pkg_Add_prio( /*| Add new prio to prio heap */ Prio_heap_pkg_Prioritynumber Prio_to_add ) { /** *| Algorithm *| Add new prio to end of heap, then "sift" it up, *| until binary heap condition is restored *| (i.e., prio_heap(n) > prio_heap(2n),prio_heap(2n+1)) **/ Prio_heap_pkg__Prio_heap_index Parent; Prio_heap_pkg__Prio_heap_index Child; Prio_heap_pkg__Num_in_prio_heap = (uint16 )((int32 ) Prio_heap_pkg__Num_in_prio_heap+1); /* Start at end of heap */ Child = (uint16 )(int32 )Prio_heap_pkg__Num_in_prio_heap; /* Loop until reach top of heap, or parent greater than new prio */ while ((int32 )Child > 1) { Parent = (uint16 )((int32 )Child/2); /* Find slot which should be greater */ if ((int32 )Prio_heap_pkg__Prio_heap[(int32 )Parent - 1] >= ( int32 )Prio_to_add) { goto loop_label__1; } /* All done if Parent is already greater */ /* Parent smaller, move it down to child's slot */ Prio_heap_pkg__Prio_heap[(int32 )Child - 1] = (uint8 )(int32 ) Prio_heap_pkg__Prio_heap[(int32 )Parent - 1]; /* Advance up to parent slot and iterate */ Child = (uint16 )(int32 )Parent; } loop_label__1:; /*| ASSERT: Prio_To_Add < Prio_Heap(Child/2) or top-of-heap */ Prio_heap_pkg__Prio_heap[(int32 )Child - 1] = (uint8 )(int32 ) Prio_to_add; } void Prio_heap_pkg_Remove_top_prio(void) /* | Remove top priority from prio heap */ { /** *| Algorithm *| Move bottom of heap to top of heap, and then "sift" it down *| until binary heap condition is restored *| (i.e., prio_heap(n) > prio_heap(2n),prio_heap(2n+1)) **/ Prio_heap_pkg_Prioritynumber Prio_to_move; /*| Priority to sift down */ Prio_heap_pkg__Prio_heap_index Parent; /*| Child = higher-prio-of (2*Parent, 2*Parent+1) */ Prio_heap_pkg__Prio_heap_index Child; Prio_heap_pkg__Prio_heap_count Parent_limit; /*| Last parent with any children */ Prio_to_move = (uint8 )(int32 )Prio_heap_pkg__Prio_heap[(int32 ) Prio_heap_pkg__Num_in_prio_heap - 1]; /** * Ensure that empty slots have min prio * This allows us to ignore special case when parent has * exactly one child, since missing child will appear to have * minimum priority. **/ Prio_heap_pkg__Prio_heap[(int32 )Prio_heap_pkg__Num_in_prio_heap - 1] = (uint8 )(int32 )Prio_heap_pkg__Min_prio; /* Shorten the heap */ Prio_heap_pkg__Num_in_prio_heap = (uint16 )((int32 ) Prio_heap_pkg__Num_in_prio_heap - 1); if ((int32 )Prio_heap_pkg__Num_in_prio_heap == 0) { /* All done if heap now empty */ return ; } /* Start at top of heap */ Parent = 1; /** * Calculate limit on parent * (do this to avoid overflow in child calculation) **/ Parent_limit = (uint16 )((int32 )Prio_heap_pkg__Num_in_prio_heap/2); /* Loop until reach bottom of heap, or prio-to-mv > both children */ while ((int32 )Parent <= (int32 )Parent_limit) { /* Determine larger "child" */ Child = (uint16 )((int32 )Parent*2); if ((int32 )Prio_heap_pkg__Prio_heap[(int32 )Child+1 - 1] > ( int32 )Prio_heap_pkg__Prio_heap[(int32 )Child - 1]) { /* 2n+1 child is greater than 2n child */ Child = (uint16 )((int32 )Child+1); } if ((int32 )Prio_to_move >= (int32 )Prio_heap_pkg__Prio_heap[( int32 )Child - 1]) { goto loop_label__2; } /* All done when slot found for prio being moved */ /* Move larger child up, and iterate with child's slot */ Prio_heap_pkg__Prio_heap[(int32 )Parent - 1] = (uint8 )(int32 ) Prio_heap_pkg__Prio_heap[(int32 )Child - 1]; Parent = (uint16 )(int32 )Child; } loop_label__2:; /** * ASSERT: Prio_To_Move > both children (2*Parent,2*Parent+1) * or slot has no children **/ /* Put prio in its new slot */ Prio_heap_pkg__Prio_heap[(int32 )Parent - 1] = (uint8 )(int32 ) Prio_to_move; } void rts_ss_mark(Root_address ); Character * rts_integer_image(int32*, Integer ); #include "ada.text_io.spc.h" void rts_ss_release(Root_address ); void Prio_heap_pkg__Print_prio_list( Prio_heap_pkg__Prio_heap_index Parent ) { Prio_heap_pkg__Prio_heap_index Child; uint8 *pointer__3; int32 dyn_temp__4[2]; Character *pointer__5; if ((int32 )Parent <= (int32 )Prio_heap_pkg__Num_in_prio_heap) { rts_ss_mark((uint8 *)&pointer__3); pointer__5 = rts_integer_image(dyn_temp__4,(int32 ) Prio_heap_pkg__Prio_heap[(int32 )Parent - 1]); Ada_Text_io_Put_line__2((Character *)pointer__5,dyn_temp__4); rts_ss_release((uint8 *)&pointer__3); if ((int32 )Parent <= (int32 )Prio_heap_pkg__Num_in_prio_heap/2 ) { Child = (uint16 )(2*(int32 )Parent); if ((int32 )Prio_heap_pkg__Prio_heap[(int32 )Child+1 - 1] > (int32 )Prio_heap_pkg__Prio_heap[(int32 )Child - 1]) { Prio_heap_pkg__Print_prio_list((uint16 )((int32 )Child+1)); Prio_heap_pkg__Print_prio_list((uint16 )(int32 )Child); } else { Prio_heap_pkg__Print_prio_list((uint16 )(int32 )Child); Prio_heap_pkg__Print_prio_list((uint16 )((int32 )Child+1)); } } } } void Prio_heap_pkg_Print_prio_heap(void) { Prio_heap_pkg__Print_prio_list(1); } ----------- prio_heap_pkg.spc --------- pragma Suppress(All_Checks); package Prio_Heap_Pkg is --| Overview --| This package maintains a "binary heap" of priorities --| allowing fast access to the highest priority in the heap. subtype PriorityNumber is Integer range 0..255; procedure Add_Prio ( --| Add new prio to prio heap Prio_To_Add : PriorityNumber ); procedure Remove_Top_Prio; --| Remove top priority from prio heap procedure Print_Prio_Heap; --| Print all priorities in priority heap, --| in priority order. end Prio_Heap_Pkg; ----------- prio_heap_pkg.bdy --------- with Ada.Text_IO; package body Prio_Heap_Pkg is --| Maintain priority heap --| Overview --| This package maintains a "binary heap" of priorities --| allowing fast access to the highest priority in the heap. Min_Prio : constant PriorityNumber := PriorityNumber'First; --| Lowest priority supported. Num_Prio : constant := PriorityNumber'Pos(PriorityNumber'Last) - PriorityNumber'Pos(PriorityNumber'First) + 1; --| Number of priorities supported type Prio_Heap_Count is range 0 .. Num_Prio + 1; --| type for count of items in prio heap --| One extra so may always assume have 2 or 0 children (see --| Remove_Prio below). subtype Prio_Heap_Index is Prio_Heap_Count range 1 .. Prio_Heap_Count'Last; --| subtype for index into prio heap Prio_Heap : array(Prio_Heap_Index) of PriorityNumber := (others => Min_Prio); --| List of priorities which might have non-empty task queue. --| This list is organized as a "binary heap" where --| Prio_Heap(n/2) > Prio_Heap(n) for n in 2..Num_In_Prio_Heap. --| Initialize to Min_Prio to simplify Remove_Prio algorithm. Num_In_Prio_Heap : Prio_Heap_Count := 0; --| Count of items in prio heap In_Prio_Heap : array(PriorityNumber) of Boolean := (others => False); --| Indication for each priority whether in prio heap Top_Prio_In_Heap : PriorityNumber renames Prio_Heap(Prio_Heap'First); --| Highest priority which might have non-empty queue procedure Add_Prio ( --| Add new prio to prio heap Prio_To_Add : PriorityNumber ) is --| Algorithm --| Add new prio to end of heap, then "sift" it up, --| until binary heap condition is restored --| (i.e., prio_heap(n) > prio_heap(2n),prio_heap(2n+1)) Parent, Child : Prio_Heap_Index; begin Num_In_Prio_Heap := Num_In_Prio_Heap + 1; -- Start at end of heap Child := Num_In_Prio_Heap; -- Loop until reach top of heap, or parent greater than new prio while Child > 1 loop Parent := Child/2; -- Find slot which should be greater exit when Prio_Heap(Parent) >= Prio_To_Add; -- All done if Parent is already greater -- Parent smaller, move it down to child's slot Prio_Heap(Child) := Prio_Heap(Parent); -- Advance up to parent slot and iterate Child := Parent; end loop; --| ASSERT: Prio_To_Add < Prio_Heap(Child/2) or top-of-heap Prio_Heap(Child) := Prio_To_Add; end Add_Prio; procedure Remove_Top_Prio --| Remove top priority from prio heap is --| Algorithm --| Move bottom of heap to top of heap, and then "sift" it down --| until binary heap condition is restored --| (i.e., prio_heap(n) > prio_heap(2n),prio_heap(2n+1)) Prio_To_Move : constant PriorityNumber := Prio_Heap(Num_In_Prio_Heap); --| Priority to sift down Parent, Child : Prio_Heap_Index; --| Child = higher-prio-of (2*Parent, 2*Parent+1) Parent_Limit : Prio_Heap_Count; --| Last parent with any children begin -- Ensure that empty slots have min prio -- This allows us to ignore special case when parent has -- exactly one child, since missing child will appear to have -- minimum priority. Prio_Heap(Num_In_Prio_Heap) := Min_Prio; -- Shorten the heap Num_In_Prio_Heap := Num_In_Prio_Heap - 1; if Num_In_Prio_Heap = 0 then -- All done if heap now empty return; end if; -- Start at top of heap Parent := 1; -- Calculate limit on parent -- (do this to avoid overflow in child calculation) Parent_Limit := Num_In_Prio_Heap / 2; -- Loop until reach bottom of heap, or prio-to-mv > both children while Parent <= Parent_Limit loop -- Determine larger "child" Child := Parent * 2; if Prio_Heap(Child + 1) > Prio_Heap(Child) then -- 2n+1 child is greater than 2n child Child := Child + 1; end if; exit when Prio_To_Move >= Prio_Heap(Child); -- All done when slot found for prio being moved -- Move larger child up, and iterate with child's slot Prio_Heap(Parent) := Prio_Heap(Child); Parent := Child; end loop; -- ASSERT: Prio_To_Move > both children (2*Parent,2*Parent+1) -- or slot has no children -- Put prio in its new slot Prio_Heap(Parent) := Prio_To_Move; end Remove_Top_Prio; procedure Print_Prio_List( --| Print all priorities in heap --| in priority order, starting at given slot Parent : Prio_Heap_Index ) is --| Algorithm --| Print prio at given slot in heap, --| Then recurse with children, higher prio first. Child : Prio_Heap_Index; begin if Parent <= Num_In_Prio_Heap then -- Print priority Ada.Text_IO.Put_Line(Integer'Image(Prio_Heap(Parent))); if Parent <= Num_In_Prio_Heap/2 then -- Parent has children, recurse on children in order Child := 2 * Parent; if Prio_Heap(Child+1) > Prio_Heap(Child) then -- Second child is higher prio Print_Prio_List(Child+1); Print_Prio_List(Child); else -- First child is higher prio Print_Prio_List(Child); Print_Prio_List(Child+1); end if; end if; end if; end Print_Prio_List; procedure Print_Prio_Heap is --| Print all priorities in priority heap, --| in priority order. begin -- Just pass the buck to the recursive routine Print_Prio_List(Prio_Heap_Index'First); end Print_Prio_Heap; ---------------------------------------------------------------------- end Prio_Heap_Pkg; ---------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada --> C Translation, was: Win CE target 1998-09-29 0:00 ` Tucker Taft @ 1998-09-30 0:00 ` dewarr 0 siblings, 0 replies; 40+ messages in thread From: dewarr @ 1998-09-30 0:00 UTC (permalink / raw) In article <F01sL5.5Ey.0.-s@inmet.camb.inmet.com>, stt@houdini.camb.inmet.com (Tucker Taft) wrote: > As an example of reasonably readable C, I have appended a translation > of a simple priority-heap package, where the automated translator did its > best to preserve comments, Ada names, etc. in the generated C. Note that > constraint checks have been suppressed in this translation, to avoid > offending the sensibilities of C programmers ;-). It is not only the sensibilities of C programmers that would be offended by putting in full constraint checking, but this would also impact the readability considerably I suspect. It is certainly the case that some subset of Ada can be represented as readable C, especially if constraint checking is suppressed, my comments were responding to the suggestion that the whole of Ada can be translated to meet this criterion, and it is no suprise to me that Tuck agrees with this assessment (all of Ada can be translated to C, but only a subset will be readable). This is actually a well known result, at least two previous commercial Ada compilers have operated by generating C, with similar results. By the way, efficiency and readability can definitely be at odds. From experiments done in one case, it appears that the use of setjmp and longjmp is generally less efficient than providing an extra parameter on every call. This is most certainly true on the SPARC, where the standard setjmp uses a kernel call -- this is by the way total incompetence, there is no requirement for this approach, and if you are translating Ada to GNU-C, you will find it far better to use the builtin setjmp and longjmp functions of this compiler. One place where the generated C will get very far from readable is packed arrays. This important feature is completely missing from C. Perhaps you can partly deal with it by macros, but only partly! Have a look at the -gnatdg output from GNAT to get an idea of what has to be generated (this is one thing that is currently handled by the front end of GNAT rather than the backend). -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada --> C Translation, was: Win CE target 1998-09-28 0:00 ` Ada --> C Translation, was: " Stefan Helfert 1998-09-29 0:00 ` Tucker Taft @ 1998-09-29 0:00 ` Robert A Duff 1998-10-10 0:00 ` Dr Amirez 1 sibling, 1 reply; 40+ messages in thread From: Robert A Duff @ 1998-09-29 0:00 UTC (permalink / raw) Stefan Helfert <helfert@galileo.mpi-hd.mpg.de> writes: > dewarr@my-dejanews.com wrote: > [...] > > Some of the trouble areas in compiling into C are > > > > 1. Arithmetic overflow checks, especially in complex > > expressions, which have to be broken down into steps > > or written in prefix notation. > > > > 2. Nested procedures, and particularly nested procedures > > with complex local declarations. > > > > 3. Subunits (hard to do anything other than create a huge > > source in which the subunits are substituted). > > > > 4. Exceptions > > > [...] > > I will say for the record, that, according to MY definition > > of readability, it is not possible to translate Ada 95 into > > readable C in all cases. What's YOUR definition of "readability"? A master C programmer doesn't have access to any of the features mentioned above (eg nested procedures), either. So of COURSE a program that could benefit from nested procedures will be more readable in Ada than in C (eg maybe the C code will have to pass extra bogus parameters, or whatever). Of course an automatic translator can't use nested procedures either. Or subunits. Or tasks. Or whatever. But, given an automatic translator from Ada to C, one ought to measure the readability of the translator output with respect to hand-written C code. Given that the hand-written C code can't do (say) exceptions in any direct way, why should one complain when the output of the Ada-to-C translator can't do it directly? In other words, we shouldn't complain if the generated C code is less readable than the Ada code; we should only complain if the generated C code is less readable than typical hand-written C code. - Bob -- Change robert to bob to get my real email address. Sorry. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada --> C Translation, was: Win CE target 1998-09-29 0:00 ` Robert A Duff @ 1998-10-10 0:00 ` Dr Amirez 1998-10-11 0:00 ` Dale Stanbrough 1998-10-13 0:00 ` Robert I. Eachus 0 siblings, 2 replies; 40+ messages in thread From: Dr Amirez @ 1998-10-10 0:00 UTC (permalink / raw) In article <wcck92nbxdh.fsf@world.std.com> Robert A Duff <bobduff@world.std.com> writes: >Stefan Helfert <helfert@galileo.mpi-hd.mpg.de> writes: > >> dewarr@my-dejanews.com wrote: >> [...] >> > Some of the trouble areas in compiling into C are >> > >> > >> > 4. Exceptions >> > Well, C didn't have exceptions for years and probably will never have it. That didn't keep it from being one of the most successful languages ever created. If you consider a feature rich language a better language then let me tell you this. I remember seeing a question on this forum that goes like this: "If a task blocks on I/O, do other tasks get a chance to run or the *process* will suspend itself, and no task will run until the process get scheduled again? " Someone responded that it's undefined. Well, I would think such an important feature should be very well defined instead of being left as an excercise for the user to find out how that is implemented on their systems. After all, isn't Ada intended to be a system programming language? You can't program systems using features that are system dependant themselves. The more features a language has, the more flaws it has. You, as an Ada programmer, probably know better than I. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada --> C Translation, was: Win CE target 1998-10-10 0:00 ` Dr Amirez @ 1998-10-11 0:00 ` Dale Stanbrough 1998-10-10 0:00 ` Dr Amirez 1998-10-13 0:00 ` Robert I. Eachus 1 sibling, 1 reply; 40+ messages in thread From: Dale Stanbrough @ 1998-10-11 0:00 UTC (permalink / raw) Dr Amirez wrote: " Well, C didn't have exceptions for years and probably will never have it. That didn't keep it from being one of the most successful languages ever created. If you consider a feature rich language a better language then let me tell you this. I remember seeing a question on this forum that goes like this: "If a task blocks on I/O, do other tasks get a chance to run or the *process* will suspend itself, and no task will run until the process get scheduled again? " Someone responded that it's undefined. Well, I would think such an important feature should be very well defined instead of being left as an excercise for the user to find out how that is implemented on their systems. After all, isn't Ada intended to be a system programming language? You can't program systems using features that are system dependant themselves. The more features a language has, the more flaws it has. You, as an Ada programmer, probably know better than I". Ok, let's put your rather simplistic analysis to the test. An issue of Communications of the ACM tested a large number of Unix utilities (vi was one of them) to the test by feeding them with a stream of randomly produced characters. A very high proportion of the programs crashed (core dumped!). This is from a simple language. Why did this happen? If it is such a simple language, surely by your logic, any program will be aok? Lets face reality. A language with more features may be harder to implement. There may be some flaws in the definition. But does it mean that the language can't be used to create reliable code? Certainly the opposite (a simple language will always produce good code) isn't true. What it really means is you have to analyze the features to see if they help you write better programs. Another recent article in Communications of the ACM had a discussion about all the terrible things that could happen in programs (it did a fault analysis of a large number of (C) programs). Guess what.. a large number of the _run time_ problems in these programs would have been _compile time_ problems in Ada. Your analysis seems to have the depth of someone comparing the space shuttle to a fireworks rocket... "Has rocket motor?" "Check!" "Takes off vertically?" "Check!" "Is firework rocket cheaper?" "Check!" "Firework rocket simpler?" "Check!" "Sheesh! why would anyone use a more complex Space shuttle when a firework rocket is cleary much more useful!" You then rather amazingly assert... "You can't program systems using features that are system dependant themselves" Once again I will point you at C. In this language the size of an integer hasn't been defined. This is a system dependent feature. By your definition you can't program systems with C. You had better ring up AT&T and tell them the bad news... Dale ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada --> C Translation, was: Win CE target 1998-10-11 0:00 ` Dale Stanbrough @ 1998-10-10 0:00 ` Dr Amirez 1998-10-11 0:00 ` Dale Stanbrough ` (2 more replies) 0 siblings, 3 replies; 40+ messages in thread From: Dr Amirez @ 1998-10-10 0:00 UTC (permalink / raw) In article <dale-1110980932270001@dale.ppp.cs.rmit.edu.au> dale@cs.rmit.edu.au (Dale Stanbrough) writes: >Dr Amirez wrote: > >" Well, C didn't have exceptions for years and probably will never have it. > That didn't keep it from being one of the most successful languages > ever created. If you consider a feature rich language a better language > then let me tell you this. I remember seeing a question on this forum > that goes like this: "If a task blocks on I/O, do other tasks get a chance > to run or the *process* will suspend itself, and no task will run > until the process get scheduled again? " > Someone responded that it's undefined. Well, I would think such > an important feature should be very well defined instead of being > left as an excercise for the user to find out how that is implemented > on their systems. After all, isn't Ada intended to be a system > programming language? You can't program systems using features that > are system dependant themselves. > The more features a language has, the more flaws it has. You, as an Ada > programmer, probably know better than I". > > > >Ok, let's put your rather simplistic analysis to the test. > >An issue of Communications of the ACM tested a large number of Unix >utilities (vi was one of them) to the test by feeding them with a stream >of randomly produced characters. A very high proportion of the programs >crashed (core dumped!). Well, any software needs testing. Much of this is the fault of UNIX vendors. I understand the bugs got reported times after times but never got fixed. I can only think of one reason: patching one thing will only make another problem emerge. That's sad. But then the time for UNIX has passed, investing into fixing UNIX bugs isn't productive. Then again, how many times does the ACM get a chance to test an OS in Ada? Theoretically such an OS will be better than UNIX/NT/LINUX, but you never know. > >This is from a simple language. Why did this happen? If it is such a >simple language, surely by your logic, any program will be aok? > > >Lets face reality. A language with more features may be harder to >implement. There may be some flaws in the definition. But does it mean >that the language can't be used to create reliable code? Certainly the >opposite (a simple language will always produce good code) isn't true. >What it really means is you have to analyze the features to see if they >help you write better programs. Another recent article in Communications >of the ACM had a discussion about all the terrible things that could >happen in programs (it did a fault analysis of a large number of (C) >programs). Guess what.. a large number of the _run time_ problems in >these programs would have been _compile time_ problems in Ada. How about I hate guessing. I will wait for a an Ada OS to come along. Linux is (used to be anyway ) a one man project. Surely an OS can't be that hard to build. Please leave AT&T out of this. They contribute greatly to the Computer Sci community. Without them I would still be working on some obscure system written in a mixture of FORTRAN, PL1 and assembly. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada --> C Translation, was: Win CE target 1998-10-10 0:00 ` Dr Amirez @ 1998-10-11 0:00 ` Dale Stanbrough 1998-10-11 0:00 ` Dr Amirez 1998-10-12 0:00 ` PC 1998-10-12 0:00 ` Ada --> C Translation, was: Win CE target dennison 2 siblings, 1 reply; 40+ messages in thread From: Dale Stanbrough @ 1998-10-11 0:00 UTC (permalink / raw) Dr Amirez wrote: "Well, any software needs testing. Much of this is the fault of UNIX vendors. I understand the bugs got reported times after times but never got fixed. I can only think of one reason: patching one thing will only make another problem emerge. That's sad. But then the time for UNIX has passed, investing into fixing UNIX bugs isn't productive. Then again, how many times does the ACM get a chance to test an OS in Ada? Theoretically such an OS will be better than UNIX/NT/LINUX, but you never know." Um, they weren't part of the OS, I was talking about the _Utilities_ such as vi, cat, etc. that come with it. The article commented on the fact that these programs had a very long history of no problems, yet were still vunerable to failure. An Ada program could well have the same faults, but given the inclusion of array bounds checking, and numerous other checks these would have either been picked up earlier, or would have resulted in a constraint_error exception - which I view as being better than a core dump. At least with a constraint error you can be reasonably assured that no other data has been corrupted and saved unwittingly due to a program running on. I don't understand why you started talking about OS developement in Ada. You seem to have a very strange way of making a point. I certainly don't understand what you are on about. "How about I hate guessing. I will wait for a an Ada OS to come along. Linux is (used to be anyway ) a one man project. Surely an OS can't be that hard to build." Ok you may hate guessing, but what i asked was a rhetorical question, so it didn't need an answer. "Please leave AT&T out of this. They contribute greatly to the Computer Sci community. Without them I would still be working on some obscure system written in a mixture of FORTRAN, PL1 and assembly." Maybe they do, but you were the one who claimed that you can't write system software with facilities that are system dependent, which is exactly what AT&T have done. I really don't understand what you are on about, and I suspect that continuing this discussion is just a waste of time. Good Bye. Dale ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada --> C Translation, was: Win CE target 1998-10-11 0:00 ` Dale Stanbrough @ 1998-10-11 0:00 ` Dr Amirez 1998-10-12 0:00 ` Larry Kilgallen 1998-10-12 0:00 ` Niklas Holsti 0 siblings, 2 replies; 40+ messages in thread From: Dr Amirez @ 1998-10-11 0:00 UTC (permalink / raw) In article <dale-1110981647250001@dale.ppp.cs.rmit.edu.au> dale@cs.rmit.edu.au (Dale Stanbrough) writes: >Dr Amirez wrote: > >"Well, any software needs testing. Much of this is the fault of UNIX > vendors. I understand the bugs got reported times after times but > never got fixed. I can only think of one reason: patching one thing > will only make another problem emerge. That's sad. But then the time > for UNIX has passed, investing into fixing UNIX bugs isn't productive. > Then again, how many times does the ACM get a chance to test an OS > in Ada? Theoretically such an OS will be better than UNIX/NT/LINUX, but > you never know." > > >Um, they weren't part of the OS, I was talking about the _Utilities_ such >as vi, cat, etc. that come with it. The article commented on the fact that >these programs had a very long history of no problems, yet were still >vunerable to failure. An Ada program could well have the same faults, >but given the inclusion of array bounds checking, and numerous other >checks these would have either been picked up earlier, or would have >resulted in a constraint_error exception - which I view as being >better than a core dump. At least with a constraint error you can be >reasonably assured that no other data has been corrupted and saved >unwittingly due to a program running on. > >I don't understand why you started talking about OS developement in >Ada. You seem to have a very strange way of making a point. I certainly >don't understand what you are on about. > > >"How about I hate guessing. I will wait for a an Ada OS to come along. > Linux is (used to be anyway ) a one man project. Surely an OS can't be that > hard to build." > >Ok you may hate guessing, but what i asked was a rhetorical question, so >it didn't need an answer. > >"Please leave AT&T out of this. They contribute greatly > to the Computer Sci community. Without them I would still be working > on some obscure system written in a mixture of FORTRAN, PL1 and assembly." > > >Maybe they do, but you were the one who claimed that you can't write >system software with facilities that are system dependent, which is >exactly what AT&T have done. I really don't understand what you are >on about, and I suspect that continuing this discussion is just a waste >of time. > >Good Bye. > >Dale i would have dropped this. But since I am so bored I might as well flame away. Well the reason why I brought the Operating systems issue up is that it's impossible to write Ada utilities without an Ada OS. But if you could build Ada utilities on UNIX that outperform UNIX C utilities then it's fine with me. Make sure you ship copies to the ACM. The core dumping has been a facility on UNIX to assist in debugging .Maybe you don't know enough about UNIX. C programs can disable the core dumping if they want to. The reason a core was left behind was for the debugger to look at. Maybe Ada programs don't have bugs so they don't have to dump cores or they contend with printing a message "Array out of bound" then exit. I feel neither approach is adequate. There are systems out there without a screen to display a message or a disk drives to dump a core. Bugs are bugs. They need to be fixed. I couldn't care less how they are handled. They just need to be fixed. Last, the undefined behaviour of C are pretty well known and well documented. It's unlikely that there is an undefined behaviour that I don't know about: A few examples are: i = i++; /* dont do this. You have been warned */ char *c = "abc"; c[0] = 0; /* don't do this. You have been warnted */ fflush(stdin); /* Don't do this. You have been warned*/ The attitude of C towards undefined behavior is "Don't do it" period. Not knowing Ada, i will have to reiterate on the example of undefined behavior on task. Basically if a task blocks on I/O then anything -absolutely anything -can happen. What is the attitude of Ada? Don't use tasks? Use tasks but do not perform I/O in tasks? Have tasks perform I/O and pray nothing bad happens? Someone here complained about C leaves so many things undefined. True. Just don't do them. It's not "Yeah, it might work for you, try it and see. " Dr Amirez ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada --> C Translation, was: Win CE target 1998-10-11 0:00 ` Dr Amirez @ 1998-10-12 0:00 ` Larry Kilgallen 1998-10-13 0:00 ` dennison 1998-10-12 0:00 ` Niklas Holsti 1 sibling, 1 reply; 40+ messages in thread From: Larry Kilgallen @ 1998-10-12 0:00 UTC (permalink / raw) In article <6vrlb4$jj$1@jupiter.cs.uml.edu>, dramirez@cs.uml.edu (Dr Amirez) writes: > Well the reason why I brought the Operating systems issue up > is that it's impossible to write Ada utilities without an > Ada OS. But if you could build Ada utilities on UNIX that > outperform UNIX C utilities then it's fine with me. Make sure > you ship copies to the ACM. I can't speak for Unix, but on VMS it is quite possible to write general purpose utilities in Ada. The trick is in the bindings that describe the operating system services to the compiler. This is no different than for C, Pascal, Fortran, Cobol or any other language. > The core dumping has been a facility on UNIX to assist > in debugging .Maybe you don't know enough about UNIX. Although VMS has a memory dump capability, I find it much more helpful to run my defective Ada program with the debugger. Then when there is a problem where I want to examine variables, the capability is right there. My conversations in the past with Unix people indicate they use the same technique. There is a class of problems where the program will fail when run without the debugger but will succeed when the debugger is present. In that case, a memory dump may be helpful, but I find this type of failure much less likely to occur with Ada than with other languages. Larry Kilgallen ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada --> C Translation, was: Win CE target 1998-10-12 0:00 ` Larry Kilgallen @ 1998-10-13 0:00 ` dennison 0 siblings, 0 replies; 40+ messages in thread From: dennison @ 1998-10-13 0:00 UTC (permalink / raw) In article <1998Oct12.162441.1@eisner>, Kilgallen@eisner.decus.org.nospam wrote: > In article <6vrlb4$jj$1@jupiter.cs.uml.edu>, dramirez@cs.uml.edu (Dr Amirez) writes: > > > Well the reason why I brought the Operating systems issue up > > is that it's impossible to write Ada utilities without an > > Ada OS. But if you could build Ada utilities on UNIX that > > outperform UNIX C utilities then it's fine with me. Make sure > > you ship copies to the ACM. > > I can't speak for Unix, but on VMS it is quite possible to write > general purpose utilities in Ada. The trick is in the bindings > that describe the operating system services to the compiler. This > is no different than for C, Pascal, Fortran, Cobol or any other > language. I can. Its quite possible for Unix and Windows NT as well. In fact its often *easier* to write Unix utilities in Ada, since you typically don't have to create and keep working one of those gawd-awful Unix makefiles. -- T.E.D. -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada --> C Translation, was: Win CE target 1998-10-11 0:00 ` Dr Amirez 1998-10-12 0:00 ` Larry Kilgallen @ 1998-10-12 0:00 ` Niklas Holsti 1 sibling, 0 replies; 40+ messages in thread From: Niklas Holsti @ 1998-10-12 0:00 UTC (permalink / raw) Dr Amirez wrote: > [ snipped a lot of quotes ] > i would have dropped this. But since I am so bored I might as > well flame away. Hoping to entertain you, I reply. > Well the reason why I brought the Operating systems issue up > is that it's impossible to write Ada utilities without an > Ada OS. That is untrue. All Ada systems have the ability to interface to the operating system. For one thing, Ada bindings to the POSIX APIs are extensively standardised. Also, I get the impression that you believe that no Ada OS exists. To my knowledge, at least two OSes have been written in Ada: the OS for the Rational R1000, and the OS for the Nokia MPS-10. (Neither machine is alive today, but this is not because of the OS implementation language.) In addition, many if not most of the run-time systems (real-time kernels) delivered with Ada compilers are written in Ada. > The core dumping has been a facility on UNIX to assist > in debugging .Maybe you don't know enough about UNIX. C programs can disable > the core dumping if they want to. The reason a core was left > behind was for the debugger to look at. Of course the problem was not that a "core" was left behind. (Having a core dump is indeed better than not having one.) The problem was that the program crashed, instead of giving a helpful error message. > Maybe Ada programs > don't have bugs so they don't have to dump cores or they contend > with printing a message "Array out of bound" then exit. I feel > neither approach is adequate. There are systems out there without > a screen to display a message or a disk drives to dump a core. > Bugs are bugs. They need to be fixed. I couldn't care less > how they are handled. They just need to be fixed. Programs have flaws. Some languages (Ada among them) check for common errors (at compile time and at run time) so that a somewhat meaningful error message can be emitted. Some languages (Ada and C++ among them) let you, the programmer, define what to do when an error is detected at run time. In some cases, the program can recover and continue; in all cases, it can issue a detailed, specific error message that helps you fix the flaw. The C language just runs on until the program is totally messed up. Want to bet in which language bugs are easier to fix? [ examples of C problems snipped ] > Not knowing Ada, i will have to reiterate on the example > of undefined behavior on task. Basically if a task blocks > on I/O then anything -absolutely anything -can happen. You are exaggerating this. What can happen is that either just this task blocks and the other tasks continue, or all tasks block until the I/O completes. The latter (undesirable) behaviour can occur in an Ada implementation under an OS such as Unix or Windows NT, if the entire Ada program has been mapped to one OS process and the I/O call is process-blocking. Exactly the same two cases can occur in a multi-threaded C program, depending on the type of threads and OS calls used. In modern Ada implementations the usual approach is to make each Ada task a thread and use I/O calls that block only the calling thread. Whichever case happens, the execution of the Ada program continues, once the I/O is completed. Only the real-time aspects are affected. Note that Ada was originally intended for bare embedded systems where this problem cannot occur. The idea was that the whole system, including I/O drivers, is written in Ada using the Ada tasking model and run-time system. In this context, the Ada standard defines the intended real-time performance quite clearly. Modern Ada implementations using threads also do this well. > What is the attitude of Ada? Don't use tasks? Use tasks > but do not perform I/O in tasks? Have tasks perform I/O > and pray nothing bad happens? The attitude is to check the compiler documentation for the blocking implications of OS interactions -- if you are using an OS. Again, this affects only real-time performance. In practice, the only case where this problem is significant for portability is where some task is waiting for an I/O that can take an indefinite time, such as reading an operator command or a network message. If your program needs this, you choose a non-blocking OS call, or check that your compiler uses such calls for Ada I/O procedures. > Someone here complained about C leaves so many things > undefined. True. Just don't do them. It's not "Yeah, it might > work for you, try it and see. " The C problems are in C itself. The Ada task blocking problem is not in Ada, but in the Ada-OS interaction. I've met many C programmers who use the "try it and see" approach. Also some Ada programmers... but it is definitely not the "Ada attitude". > Dr Amirez Niklas Holsti ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada --> C Translation, was: Win CE target 1998-10-10 0:00 ` Dr Amirez 1998-10-11 0:00 ` Dale Stanbrough @ 1998-10-12 0:00 ` PC 1998-10-12 0:00 ` Operating System in Ada (was Ada --> C Translation) Larry Kilgallen 1998-10-12 0:00 ` Ada --> C Translation, was: Win CE target dennison 2 siblings, 1 reply; 40+ messages in thread From: PC @ 1998-10-12 0:00 UTC (permalink / raw) Hello, > How about I hate guessing. I will wait for a an Ada OS to come along. > Linux is (used to be anyway ) a one man project. Surely an OS can't be that > hard to build. That's actually an interesting proposal... anyone undertaken a OS written completely in Ada yet? PC ^ permalink raw reply [flat|nested] 40+ messages in thread
* Operating System in Ada (was Ada --> C Translation) 1998-10-12 0:00 ` PC @ 1998-10-12 0:00 ` Larry Kilgallen 1998-10-12 0:00 ` dennison ` (3 more replies) 0 siblings, 4 replies; 40+ messages in thread From: Larry Kilgallen @ 1998-10-12 0:00 UTC (permalink / raw) In article <philip-ya02408000R1210980953070001@news.cs.uwa.edu.au>, philip@cs.uwa.edu.au (PC) writes: > Hello, > >> How about I hate guessing. I will wait for a an Ada OS to come along. >> Linux is (used to be anyway ) a one man project. Surely an OS can't be that >> hard to build. > > That's actually an interesting proposal... anyone undertaken a OS written > completely in Ada yet? The operating system that most people would think about copying first is Unix -- and that seems like a non-starter from its anti-Ada interfaces (null-terminated strings and the like). Yes it is possible to interact, but it is not in the "spirit" of Ada. What was the last totally new operating system to achieve prominence ? I suppose it was MS-DOS or MacOS. VMS, Unix, VM etc. all seem older. Larry Kilgallen ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Operating System in Ada (was Ada --> C Translation) 1998-10-12 0:00 ` Operating System in Ada (was Ada --> C Translation) Larry Kilgallen @ 1998-10-12 0:00 ` dennison 1998-10-12 0:00 ` Chris Morgan ` (2 subsequent siblings) 3 siblings, 0 replies; 40+ messages in thread From: dennison @ 1998-10-12 0:00 UTC (permalink / raw) In article <1998Oct12.072036.1@eisner>, Kilgallen@eisner.decus.org.nospam wrote: > What was the last totally new operating system to achieve prominence ? > I suppose it was MS-DOS or MacOS. VMS, Unix, VM etc. all seem older. I'd say WindowsNT, but I suppose it all depends on your definition of "totally new" and "prominence". One could certainly argue against NT based on its Windows and VMS influences. Of course, if NT doesn't count, then MS-DOS shouldn't either. -- T.E.D. -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Operating System in Ada (was Ada --> C Translation) 1998-10-12 0:00 ` Operating System in Ada (was Ada --> C Translation) Larry Kilgallen 1998-10-12 0:00 ` dennison @ 1998-10-12 0:00 ` Chris Morgan 1998-10-13 0:00 ` Larry Kilgallen ` (2 more replies) 1998-10-12 0:00 ` Tom Moran 1998-10-21 0:00 ` Van Snyder 3 siblings, 3 replies; 40+ messages in thread From: Chris Morgan @ 1998-10-12 0:00 UTC (permalink / raw) kilgallen@eisner.decus.org (Larry Kilgallen) writes: > The operating system that most people would think about copying first > is Unix -- and that seems like a non-starter from its anti-Ada interfaces > (null-terminated strings and the like). Yes it is possible to interact, > but it is not in the "spirit" of Ada. I totally disagree with this. My view of Ada strings is that they are a higher level construct than C style strings. I believe at least some Ada implementations on top of Unix simply use many of the standard C library's string functions under the hood. I may be wrong but isn't a null-terminated string a valid representation of an Ada string? Chris -- Chris Morgan <mihalis at ix.netcom.com> http://www.netcom.com/~mihalis ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Operating System in Ada (was Ada --> C Translation) 1998-10-12 0:00 ` Chris Morgan @ 1998-10-13 0:00 ` Larry Kilgallen 1998-10-13 0:00 ` Dale Stanbrough 1998-10-14 0:00 ` dewarr 2 siblings, 0 replies; 40+ messages in thread From: Larry Kilgallen @ 1998-10-13 0:00 UTC (permalink / raw) In article <87d87xmdkn.fsf@mihalis.ix.netcom.com>, Chris Morgan <mihalis@ix.netcom.com> writes: > kilgallen@eisner.decus.org (Larry Kilgallen) writes: > >> The operating system that most people would think about copying first >> is Unix -- and that seems like a non-starter from its anti-Ada interfaces >> (null-terminated strings and the like). Yes it is possible to interact, >> but it is not in the "spirit" of Ada. > > I totally disagree with this. My view of Ada strings is that they are > a higher level construct than C style strings. I believe at least some > Ada implementations on top of Unix simply use many of the standard C > library's string functions under the hood. I may be wrong but isn't a > null-terminated string a valid representation of an Ada string? Ada strings allow a null in the middle, without terminating the string. To the extent that an operating system accepts that, it would behave quite differently from what a C programmer would expect, and would not match Unix. I believe the null termination is defined in the C standard. Larry KIlgallen ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Operating System in Ada (was Ada --> C Translation) 1998-10-12 0:00 ` Chris Morgan 1998-10-13 0:00 ` Larry Kilgallen @ 1998-10-13 0:00 ` Dale Stanbrough 1998-10-14 0:00 ` dewarr 2 siblings, 0 replies; 40+ messages in thread From: Dale Stanbrough @ 1998-10-13 0:00 UTC (permalink / raw) Chris Morgan wrote: "I totally disagree with this. My view of Ada strings is that they are a higher level construct than C style strings. I believe at least some Ada implementations on top of Unix simply use many of the standard C library's string functions under the hood. I may be wrong but isn't a null-terminated string a valid representation of an Ada string?" Yes, the Ada string could have an Ascii.Nul at the end of it, so long as it never appeared in the array. However it still would be of no use to represent C style strings. For example... A : String (1..10); Last : Integer; Get_Line (A, Last); If Last is 5, then don't expect a \0 at position 6! (there may be one at position 11 however). Dale ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Operating System in Ada (was Ada --> C Translation) 1998-10-12 0:00 ` Chris Morgan 1998-10-13 0:00 ` Larry Kilgallen 1998-10-13 0:00 ` Dale Stanbrough @ 1998-10-14 0:00 ` dewarr 2 siblings, 0 replies; 40+ messages in thread From: dewarr @ 1998-10-14 0:00 UTC (permalink / raw) In article <87d87xmdkn.fsf@mihalis.ix.netcom.com>, Chris Morgan <mihalis@ix.netcom.com> wrote: > kilgallen@eisner.decus.org (Larry Kilgallen) writes: > > > The operating system that most people would think about copying first > > is Unix -- and that seems like a non-starter from its anti-Ada interfaces > > (null-terminated strings and the like). Yes it is possible to interact, > > but it is not in the "spirit" of Ada. > > I totally disagree with this. My view of Ada strings is that they are > a higher level construct than C style strings. I believe at least some > Ada implementations on top of Unix simply use many of the standard C > library's string functions under the hood. I may be wrong but isn't a > null-terminated string a valid representation of an Ada string? > > Chris It is conceivable, but it is certainly not a likely representation, since it does not handle the case of slices without copies. And in any case you need to store the lower bound, so why not the length as well. Robert Dewar -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Operating System in Ada (was Ada --> C Translation) 1998-10-12 0:00 ` Operating System in Ada (was Ada --> C Translation) Larry Kilgallen 1998-10-12 0:00 ` dennison 1998-10-12 0:00 ` Chris Morgan @ 1998-10-12 0:00 ` Tom Moran 1998-10-12 0:00 ` Brian Rogoff 1998-10-13 0:00 ` Tucker Taft 1998-10-21 0:00 ` Van Snyder 3 siblings, 2 replies; 40+ messages in thread From: Tom Moran @ 1998-10-12 0:00 UTC (permalink / raw) What constitutes an Operating System? An embedded kernel? Does the Patriot missile have an OS? If so, is it written in Ada? If so, does that count? ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Operating System in Ada (was Ada --> C Translation) 1998-10-12 0:00 ` Tom Moran @ 1998-10-12 0:00 ` Brian Rogoff 1998-10-13 0:00 ` dennison 1998-10-13 0:00 ` Tucker Taft 1 sibling, 1 reply; 40+ messages in thread From: Brian Rogoff @ 1998-10-12 0:00 UTC (permalink / raw) On Mon, 12 Oct 1998, Tom Moran wrote: > What constitutes an Operating System? An embedded kernel? Does the > Patriot missile have an OS? If so, is it written in Ada? If so, does > that count? Darn it, you beat me to the punch! Some people have mentioned an early version of RTEMS (the Ada version of RTEMS is deceased now I think) and one called "PULSE" I think. A colleague at a company I worked at told me that he had written an OS kernel in Ada 83 while in graduate school without much trouble. It all depends on what one means by OS. If one means a complete Unix clone, then no, I don't think one has been written in Ada, and it would be silly to do so since Unix users expect C APIs. OTOH, a complete new OS functionally similar to Unix/NT/VMS/AS4000/... in Ada would be an interesting research project. It can obviously be done, since Ada-95 provides all of the capabilities of C, and much more. So, like Dale, I have no idea what kind of point "Dr Amirez" is trying to make. -- Brian ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Operating System in Ada (was Ada --> C Translation) 1998-10-12 0:00 ` Brian Rogoff @ 1998-10-13 0:00 ` dennison 1998-10-13 0:00 ` Brian Rogoff 0 siblings, 1 reply; 40+ messages in thread From: dennison @ 1998-10-13 0:00 UTC (permalink / raw) In article <Pine.BSF.4.02A.9810121002380.15516-100000@shell5.ba.best.com>, Brian Rogoff <bpr@shell5.ba.best.com> wrote: > silly to do so since Unix users expect C APIs. OTOH, a complete new OS > functionally similar to Unix/NT/VMS/AS4000/... in Ada would be an > interesting research project. It can obviously be done, since Ada-95 > provides all of the capabilities of C, and much more. So, like Dale, I As a (part-time) C.S. graduate student I suppose I'm in a position to take on such a project, but I have to say I don't see what the value of it would be. It might be somewhat interesting to folks here that it had been done. But why would anyone else care in the slightest? I picture the conversation going something like this: Me : Hey, I just implemented my own Operating System! Other person : Yeah? What's it do? Me : Well....nothing really. But I wrote it in Ada!! Me: : Hey. Wait! Where're you going? For anyone really interested in toying with this, I have two references that may be handy. "Operating System Design, The XINU Approach" by Douglas Comer and Timothy Fossum implements and explains (and provides) the code for a small Unix-like OS that will run on a PC clone. "The Oberon System" by (I believe) Martin Reiser and Niklaus Wirth goes over the design and code for a small Object-Oriented OS (and compiler!). -- T.E.D. -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Operating System in Ada (was Ada --> C Translation) 1998-10-13 0:00 ` dennison @ 1998-10-13 0:00 ` Brian Rogoff 0 siblings, 0 replies; 40+ messages in thread From: Brian Rogoff @ 1998-10-13 0:00 UTC (permalink / raw) On Tue, 13 Oct 1998 dennison@telepath.com wrote: > In article <Pine.BSF.4.02A.9810121002380.15516-100000@shell5.ba.best.com>, > Brian Rogoff <bpr@shell5.ba.best.com> wrote: > > > silly to do so since Unix users expect C APIs. OTOH, a complete new OS > > functionally similar to Unix/NT/VMS/AS4000/... in Ada would be an > > interesting research project. It can obviously be done, since Ada-95 > > provides all of the capabilities of C, and much more. So, like Dale, I > > As a (part-time) C.S. graduate student I suppose I'm in a position to take on > such a project, but I have to say I don't see what the value of it would be. > It might be somewhat interesting to folks here that it had been done. But why > would anyone else care in the slightest? It would depend of course on what you implemented. I didn't say that if you just implemented some vanilla OS that the world would suddenly accept Ada as an obviously superior (to me at least ;-) system implementation language. > I picture the conversation going something like this: > Me : Hey, I just implemented my own Operating System! > Other person : Yeah? What's it do? > Me : Well....nothing really. But I wrote it in Ada!! Well, here is where you have to differentiate what you are planning to write from what already exists. How about writing a research OS where the answer to that question is something, rather than "nothing really", for some value of something. No one cares if you implement something that already exists in Ada. Now the interesting question becomes what that "something" is supposed to be. Let me suggest Ted that you add EROS to the list of OSes you're looking at (http://www.cis.upenn.edu/~eros/) as well as its ancestor KeyKOS (http://www.cis.upenn.edu/~KeyKOS/) and some others like AS400 and the defunct GNU Hurd. > For anyone really interested in toying with this, I have two references that > may be handy. "Operating System Design, The XINU Approach" by Douglas Comer > and Timothy Fossum implements and explains (and provides) the code for a > small Unix-like OS that will run on a PC clone. "The Oberon System" by (I > believe) Martin Reiser and Niklaus Wirth goes over the design and code for a > small Object-Oriented OS (and compiler!). If you want to do a Unix-like OS, there is no point in exactly duplicating Unix. Rather, think of some features of Unix OSes which would be better implemented in Ada 95, like STREAMS, and take it from there. -- Brian ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Operating System in Ada (was Ada --> C Translation) 1998-10-12 0:00 ` Tom Moran 1998-10-12 0:00 ` Brian Rogoff @ 1998-10-13 0:00 ` Tucker Taft 1 sibling, 0 replies; 40+ messages in thread From: Tucker Taft @ 1998-10-13 0:00 UTC (permalink / raw) Tom Moran (tmoran@bix.com) wrote: : What constitutes an Operating System? An embedded kernel? Does the : Patriot missile have an OS? If so, is it written in Ada? Yes, and yes. (Actually, I don't know anything about the missiles per se. I know about the Patriot ground support system, which is the one that does all the hard work of tracking incoming missiles and choosing where and when to fire. That was written in Jovial, but has now been rewritten in Ada 95.) : ... If so, does that count? There are plenty of real-time executives written in Ada (perhaps too many ;-). Also, essentially every Ada run-time kernel is written in Ada, and it has a number of operating-system-like functions. The big pain in building your own commercial operating system is keeping up with all the quirks of the hardware which keep evolving, like virtual memory systems, serial devices, timers, interrupt controllers, network interfaces, graphics subsystems, disk drives, etc., etc., etc. Even if the Instruction Set Architecture (ISA) is relatively stable, nothing else is, in the hardware world. -- -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Burlington, MA USA An AverStar Company ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Operating System in Ada (was Ada --> C Translation) 1998-10-12 0:00 ` Operating System in Ada (was Ada --> C Translation) Larry Kilgallen ` (2 preceding siblings ...) 1998-10-12 0:00 ` Tom Moran @ 1998-10-21 0:00 ` Van Snyder 1998-10-22 0:00 ` Tom Moran 3 siblings, 1 reply; 40+ messages in thread From: Van Snyder @ 1998-10-21 0:00 UTC (permalink / raw) In article <1998Oct12.072036.1@eisner>, kilgallen@eisner.decus.org (Larry Kilgallen) writes: > In article <philip-ya02408000R1210980953070001@news.cs.uwa.edu.au>, philip@cs.uwa.edu.au (PC) writes: > > Hello, > > > >> How about I hate guessing. I will wait for a an Ada OS to come along. > >> Linux is (used to be anyway ) a one man project. Surely an OS can't be that > >> hard to build. > > > > That's actually an interesting proposal... anyone undertaken a OS written > > completely in Ada yet? > > The operating system that most people would think about copying first > is Unix -- and that seems like a non-starter from its anti-Ada interfaces > (null-terminated strings and the like). Yes it is possible to interact, > but it is not in the "spirit" of Ada. > > What was the last totally new operating system to achieve prominence ? > I suppose it was MS-DOS or MacOS. VMS, Unix, VM etc. all seem older. > > Larry Kilgallen Multics was over 85% written in PL\1, so there's some precedent for writing an OS in a higher-level language than PDP-11 assembler (also known as C). -- What fraction of Americans believe | Van Snyder Wrestling is real and NASA is fake? | vsnyder@math.jpl.nasa.gov ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Operating System in Ada (was Ada --> C Translation) 1998-10-21 0:00 ` Van Snyder @ 1998-10-22 0:00 ` Tom Moran 0 siblings, 0 replies; 40+ messages in thread From: Tom Moran @ 1998-10-22 0:00 UTC (permalink / raw) >Multics was over 85% written in PL\1, so there's some precedent for writing >an OS in a higher-level language than PDP-11 assembler (also known as C). And the B5500 OS was about 99% in Burroughs Algol. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada --> C Translation, was: Win CE target 1998-10-10 0:00 ` Dr Amirez 1998-10-11 0:00 ` Dale Stanbrough 1998-10-12 0:00 ` PC @ 1998-10-12 0:00 ` dennison 1998-10-12 0:00 ` Larry Kilgallen 1998-10-14 0:00 ` dewarr 2 siblings, 2 replies; 40+ messages in thread From: dennison @ 1998-10-12 0:00 UTC (permalink / raw) In article <6vp23h$hc3$1@jupiter.cs.uml.edu>, dramirez@cs.uml.edu (Dr Amirez) wrote: > Linux is (used to be anyway ) a one man project. Surely an OS can't be that > hard to build. Please leave AT&T out of this. They contribute greatly :-)) Oh my! That's a good one! I wonder if that's what Microsoft managers are telling the Windows NT 5.0 team right now. :-) -- T.E.D. -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada --> C Translation, was: Win CE target 1998-10-12 0:00 ` Ada --> C Translation, was: Win CE target dennison @ 1998-10-12 0:00 ` Larry Kilgallen 1998-10-14 0:00 ` dewarr 1 sibling, 0 replies; 40+ messages in thread From: Larry Kilgallen @ 1998-10-12 0:00 UTC (permalink / raw) In article <6vtams$gir$1@nnrp1.dejanews.com>, dennison@telepath.com writes: > I wonder if that's what Microsoft managers are telling the Windows NT 5.0 team > right now. :-) The captain wants to water-ski ? ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada --> C Translation, was: Win CE target 1998-10-12 0:00 ` Ada --> C Translation, was: Win CE target dennison 1998-10-12 0:00 ` Larry Kilgallen @ 1998-10-14 0:00 ` dewarr 1998-10-14 0:00 ` Andi Kleen 1 sibling, 1 reply; 40+ messages in thread From: dewarr @ 1998-10-14 0:00 UTC (permalink / raw) In article <6vp23h$hc3$1@jupiter.cs.uml.edu>, dramirez@cs.uml.edu (Dr Amirez) wrote: > Linux is (used to be anyway ) a one man project. Surely an OS can't be that > hard to build. Please leave AT&T out of this. They contribute greatly That's a completely absurd characterization of Linux. The existence of Linux is the culmination of the work of many people working on many things. Yes, most certainly the kernel that Linus originally wrote was a critical component, but an OS is much more than a kernel, and the work of hundreds of people, perhaps thousands has gone into creating the operating system that we know as Linux. In particular, the GNU project provided a large set of critical components, including most importantly the compilers that made the project possible, as well as many other important utilities. Robert Dewar -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada --> C Translation, was: Win CE target 1998-10-14 0:00 ` dewarr @ 1998-10-14 0:00 ` Andi Kleen 0 siblings, 0 replies; 40+ messages in thread From: Andi Kleen @ 1998-10-14 0:00 UTC (permalink / raw) dewarr@my-dejanews.com writes: > In article <6vp23h$hc3$1@jupiter.cs.uml.edu>, > dramirez@cs.uml.edu (Dr Amirez) wrote: > > > Linux is (used to be anyway ) a one man project. Surely an OS can't be that > > hard to build. Please leave AT&T out of this. They contribute greatly > > That's a completely absurd characterization of Linux. The existence of Linux > is the culmination of the work of many people working on many things. Yes, > most certainly the kernel that Linus originally wrote was a critical > component, but an OS is much more than a kernel, and the work of hundreds of > people, perhaps thousands has gone into creating the operating system that we > know as Linux. In particular, the GNU project provided a large set of > critical components, including most importantly the compilers that made the > project possible, as well as many other important utilities. Also the Linux kernel is definitely not a one-man project, although it has a chief architect (Linus Torvalds). It consists of lots of separated subsystems (kernel core, networking, file systems, isdn, drivers, scsi, console code, tty subsystem, ...) and has also separated architecture specific code sections. All these have their own maintainers or groups of maintainers with only minor overlap. The largest part of Linux are the drivers which have all their own maintainer. Then there are of course lots of other important parts of the systems which are developed by other people, like XFree86 or the C Library. To get back on the topic. Simple OS without advanced features like networking or virtual memory are not that difficult to build. For an example see UCOS. Another smaller OS available in source is vsta (it has virtual memory and networking, but it still much simpler than Linux) These are writen in C, but they probably could be writen in Ada as well. -Andi ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada --> C Translation, was: Win CE target 1998-10-10 0:00 ` Dr Amirez 1998-10-11 0:00 ` Dale Stanbrough @ 1998-10-13 0:00 ` Robert I. Eachus 1998-10-14 0:00 ` Samuel Mize 1 sibling, 1 reply; 40+ messages in thread From: Robert I. Eachus @ 1998-10-13 0:00 UTC (permalink / raw) In article <6vobnk$vt9$1@jupiter.cs.uml.edu> dramirez@cs.uml.edu (Dr Amirez) writes: > ... If you consider a feature rich language a better language > then let me tell you this. I remember seeing a question on this forum > that goes like this: "If a task blocks on I/O, do other tasks get a chance > to run or the *process* will suspend itself, and no task will run > until the process get scheduled again? " > Someone responded that it's undefined. Well, I would think such > an important feature should be very well defined instead of being > left as an excercise for the user to find out how that is implemented > on their systems. I suspect that you misheard. The correct answer is not that it is undefined, but that it is not defined unless the implementation supports the Systems Programming Annex. (In particular, section C.3, Interrupt Support.) But this misses the point. The real reason it is not defined in the core standard is that for some purposes, you need to be able to control things like tasking policies. The Real-Time Systems annex allows the programmer to change the task dispatching policy. Also, some implementations have different run-time libraries available with support for different policies. So the real answer is that, if it matters and you don't like the standard policy, read annex D, and choose a policy that you do like. > After all, isn't Ada intended to be a system programming language? Yes, especially if the System Programming annex is supported. ;-) (Actually, I suspect that most, if not all compilers try to support annex C.) > You can't program systems using features that are system dependant > themselves. Huh? The SP annex has nine implementation-defined characteristics that are required to be documented. For the most part they are things which MUST be implementation dependent, such as what interrupts the hardware has, or the op-codes for machine instructions. > The more features a language has, the more flaws it has. You, as an > Ada programmer, probably know better than I. No, I don't know that. I do know that if the language is at least as powerful as Peano arithmetic, it is either incomplete or inconsistant. The Ada community puts lots of effort into being consistant, but does have well marked doors you can use if you need completeness. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada --> C Translation, was: Win CE target 1998-10-13 0:00 ` Robert I. Eachus @ 1998-10-14 0:00 ` Samuel Mize 1998-10-16 0:00 ` Tasking/blocking system calls (was: Ada --> C Translation) Mats Weber 0 siblings, 1 reply; 40+ messages in thread From: Samuel Mize @ 1998-10-14 0:00 UTC (permalink / raw) In article <6vobnk$vt9$1@jupiter.cs.uml.edu> dramirez@cs.uml.edu (Dr Amirez) writes: > ... If you consider a feature rich language a better language > then let me tell you this. I remember seeing a question on this forum > that goes like this: "If a task blocks on I/O, do other tasks get a chance > to run or the *process* will suspend itself, and no task will run > until the process get scheduled again? " > Someone responded that it's undefined. Well, I would think such > an important feature should be very well defined instead of being > left as an excercise for the user to find out how that is implemented > on their systems. By golly, he's right. we should pick one way and stick to it. If somebody needs a different one later, he can make up his own darn language. Seriously, I/O blocking is only ambiguous for the predefined I/O packages, which are convenience packages. Ada was originally defined for embedded systems. If I'm building a real-time simulator, or an embedded radio system, or a crypto module, I really don't care whether Text_IO blocks the process or not. I'm never going to use it anyway, I'm going to be watching I/O ports with machine-specific code. Also, if I recall correctly, this WAS defined for Ada 83, by implication at least[1]. In Ada 95 the situation was improved by making it LESS defined. This lets vendors offer more options, and makes it cheaper to put Ada on new targets. Your discussion seems to assume this model for development: 1. Get compiler 2. Write program 3. Find out how compiler implements critical features The Ada community tends to put step 3 before step 1. Actually, though, much of the commercial C community uses your model. They buy a box, and they use whatever compiler came with the box. Why, of course you use the vendor's C compiler -- how else do you get all their system-specific libraries? But, of course, those aren't actually part of the language, so it's OK for their definitions to wander all over the map. > You can't program systems using features that are system dependant > themselves. I see. That must be why most of the system code I've seen is shot through with IFDEFs like cancer. You tell the compiler or make utility which versions of all the system calls you have available, and it tries to assemble a version of the program that will work. The Ada approach is to start by selecting a compiler that does what you need. Both approaches work. Neither works with the other technology. > The more features a language has, the more flaws it has. You, as an > Ada programmer, probably know better than I. I assume you're saying that a more complex system has more opportunities for bugs[2]. However, that argument ignores the fact that these language features replace user-written code. Ada was designed to provide features that most embedded systems already had, but which were hand-built in system after system. Most of the embedded community's programs need some form of multi-tasking, for example. It's a LOT less error-prone to have one implementation of tasking, that gets exercised by hundreds of projects, and that everyone tests the BLEEP out of. You wind up with a very solid tasking implementation. The alternative gives you a very simple language, everybody implements tasking separately (costing a small fortune), and lots of bugs wind up in delivered systems. By the way, Dr Amirez, my news feed doesn't seem to pick you up -- I'm replying to another reply to your post -- so please email me if you reply. Thanks. Best, Sam Mize [1] A lower-priority tasks's processing -- even a system call -- should not block a higher-priority task that becomes ready. Some implementations failed to get that right, and it wasn't tested by the validation suite, so some compilers that blocked on I/O got into the community. Which is why you heard the question at all. [2] I'm assuming this meant "You, as an Ada programmer, probably know this even better than I do." However, I won't ARGUE with the statement as written. :-) -- Samuel Mize -- smize@imagin.net (home email) -- Team Ada Fight Spam: see http://www.cauce.org/ \\\ Smert Spamonam ^ permalink raw reply [flat|nested] 40+ messages in thread
* Tasking/blocking system calls (was: Ada --> C Translation) 1998-10-14 0:00 ` Samuel Mize @ 1998-10-16 0:00 ` Mats Weber 0 siblings, 0 replies; 40+ messages in thread From: Mats Weber @ 1998-10-16 0:00 UTC (permalink / raw) Samuel Mize wrote: > By golly, he's right. we should pick one way and stick to it. If > somebody needs a different one later, he can make up his own darn > language. You can't pick one way for all purposes. Some systems need tasking that is faster or different from kernel threads, while other systems need tasks to be implemented as kernel threads. See e.g. the GNAT documentation for reasons to choose between tasking runtimes. > Seriously, I/O blocking is only ambiguous for the predefined I/O > packages, which are convenience packages. Ada was originally defined > for embedded systems. If I'm building a real-time simulator, or an > embedded radio system, or a crypto module, I really don't care whether > Text_IO blocks the process or not. I'm never going to use it anyway, > I'm going to be watching I/O ports with machine-specific code. ... which could also block the whole process. The reason why Text_IO blocked the whole process in non-kernel-threads tasking implemenetations does not come from Text_IO itself, but from the underlying machine-specific code used to implement Text_IO. > Also, if I recall correctly, this WAS defined for Ada 83, by > implication at least[1]. In Ada 95 the situation was improved by > making it LESS defined. This lets vendors offer more options, > and makes it cheaper to put Ada on new targets. > [...] > [1] A lower-priority tasks's processing -- even a system call -- > should not block a higher-priority task that becomes ready. Some > implementations failed to get that right, and it wasn't tested by > the validation suite, so some compilers that blocked on I/O got > into the community. Which is why you heard the question at all. OK, it was defined, but that is not something you can reasonably enforce on any system without kernel threads. Implementing this on e.g. SunOS (pre-Solaris), AIX 3.x or VMS 5.x, would either require the OS to be modified, or some very unreasonble implementation of tasking, or making all potentially blocking system calls go through an extra layer. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Win CE target 1998-09-20 0:00 Win CE target William A Whitaker 1998-09-20 0:00 ` Tucker Taft @ 1998-09-20 0:00 ` dewarr 1998-09-20 0:00 ` dewarr 1998-09-23 0:00 ` falis 3 siblings, 0 replies; 40+ messages in thread From: dewarr @ 1998-09-20 0:00 UTC (permalink / raw) In article <3604A4C6.8C4@erols.com>, whitaker@erols.com wrote: > Is there such a thing as an Ada 95 Win CE target. Does it make sense? > I have never seen, touched or smelled a Win CE so I have no idea if it > is possible or desirable. > > Whitaker Well first, Win CE is available for multiple architectures, so you are talking about a family of ports rather than a single port (it is much like asking if there is an Ada 95 Unix target). The targets for Win CE are all familiar ones (e.g. x86) so it certainly would not be impossible to create a Win CE port. As with other Microsoft products, probably the biggest problem would be Microsoft's annoying habit of keeping things secret (e.g. NT is the only kernel based system where the kernel interface is secret, and the debugging formats are secret). Still people have (with effort!) managed to figure out many of the details for NT, and probably Win CE would be no worse. Probably the most practical approach is to try a GNAT port. We have had no customer interest in such a port so we have not investigated this, and as far as we know, no one else has worked on a GNAT Win CE port. Most certainly a port of Ada to Win CE is possible, practical, and desirable! I would also like to see a GNAT port for the Palm Pilot, which is also possible, practical and desirable. Again with PP, you run into annoying proprietary secrecy (the PP license, which supposedly you agree to by just opening your PP says that you recognize that the user interface of the PP is a valuable trade secret of 3COM which you will not disclose to any unauthorized third party :-) Robert Dewar Ada Core Technologies -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Win CE target 1998-09-20 0:00 Win CE target William A Whitaker 1998-09-20 0:00 ` Tucker Taft 1998-09-20 0:00 ` Win CE target dewarr @ 1998-09-20 0:00 ` dewarr 1998-09-23 0:00 ` falis 3 siblings, 0 replies; 40+ messages in thread From: dewarr @ 1998-09-20 0:00 UTC (permalink / raw) In article <3604A4C6.8C4@erols.com>, whitaker@erols.com wrote: > Is there such a thing as an Ada 95 Win CE target. Does it make sense? > I have never seen, touched or smelled a Win CE so I have no idea if it > is possible or desirable. > > Whitaker Well first, Win CE is available for multiple architectures, so you are talking about a family of ports rather than a single port (it is much like asking if there is an Ada 95 Unix target). The targets for Win CE are all familiar ones (e.g. x86) so it certainly would not be impossible to create a Win CE port. As with other Microsoft products, probably the biggest problem would be Microsoft's annoying habit of keeping things secret (e.g. NT is the only kernel based system where the kernel interface is secret, and the debugging formats are secret). Still people have (with effort!) managed to figure out many of the details for NT, and probably Win CE would be no worse. Probably the most practical approach is to try a GNAT port. We have had no customer interest in such a port so we have not investigated this, and as far as we know, no one else has worked on a GNAT Win CE port. Robert Dewar Ada Core Technologies -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Win CE target 1998-09-20 0:00 Win CE target William A Whitaker ` (2 preceding siblings ...) 1998-09-20 0:00 ` dewarr @ 1998-09-23 0:00 ` falis 3 siblings, 0 replies; 40+ messages in thread From: falis @ 1998-09-23 0:00 UTC (permalink / raw) I've already been able to run ObjectAda for Windows executables on the Win-CE x86 simulator (which seems to be of little practical use, since there don't appear to be any real x86 devices running ce). Using the win-ce sdk, link the OA object modules with subsystem=<some magic win ce type>. The main has to be a winmain. Sorry about the missing details - did this a few months back. - Ed ^ permalink raw reply [flat|nested] 40+ messages in thread
end of thread, other threads:[~1998-10-22 0:00 UTC | newest] Thread overview: 40+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1998-09-20 0:00 Win CE target William A Whitaker 1998-09-20 0:00 ` Tucker Taft 1998-09-21 0:00 ` dennison 1998-09-21 0:00 ` dewarr 1998-09-28 0:00 ` Ada --> C Translation, was: " Stefan Helfert 1998-09-29 0:00 ` Tucker Taft 1998-09-30 0:00 ` dewarr 1998-09-29 0:00 ` Robert A Duff 1998-10-10 0:00 ` Dr Amirez 1998-10-11 0:00 ` Dale Stanbrough 1998-10-10 0:00 ` Dr Amirez 1998-10-11 0:00 ` Dale Stanbrough 1998-10-11 0:00 ` Dr Amirez 1998-10-12 0:00 ` Larry Kilgallen 1998-10-13 0:00 ` dennison 1998-10-12 0:00 ` Niklas Holsti 1998-10-12 0:00 ` PC 1998-10-12 0:00 ` Operating System in Ada (was Ada --> C Translation) Larry Kilgallen 1998-10-12 0:00 ` dennison 1998-10-12 0:00 ` Chris Morgan 1998-10-13 0:00 ` Larry Kilgallen 1998-10-13 0:00 ` Dale Stanbrough 1998-10-14 0:00 ` dewarr 1998-10-12 0:00 ` Tom Moran 1998-10-12 0:00 ` Brian Rogoff 1998-10-13 0:00 ` dennison 1998-10-13 0:00 ` Brian Rogoff 1998-10-13 0:00 ` Tucker Taft 1998-10-21 0:00 ` Van Snyder 1998-10-22 0:00 ` Tom Moran 1998-10-12 0:00 ` Ada --> C Translation, was: Win CE target dennison 1998-10-12 0:00 ` Larry Kilgallen 1998-10-14 0:00 ` dewarr 1998-10-14 0:00 ` Andi Kleen 1998-10-13 0:00 ` Robert I. Eachus 1998-10-14 0:00 ` Samuel Mize 1998-10-16 0:00 ` Tasking/blocking system calls (was: Ada --> C Translation) Mats Weber 1998-09-20 0:00 ` Win CE target dewarr 1998-09-20 0:00 ` dewarr 1998-09-23 0:00 ` falis
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox