Translation of IBM Basic Assembler to C?
Howard S Shubs
commercial service?
--
While its true that "you can't fix stupid", apparently you
can package it up and sell it. -- fnorgby on TMBO
Anne & Lynn Wheeler
> Does anyone know of an automated method for doing this? Maybe a
> commercial service?
misc. topic drift
i had done this pli program in the early 70s that read assembler listing
and one of the things it spit out was pli/pascal like psuedo code
(it was later looked at possibly spitting out pl.8 code). misc.
past posts mentioning program
http://www.garlic.com/~lynn/94.html#12 360 "OS" & "TSS" assemblers
http://www.garlic.com/~lynn/2000d.html#36 Assembly language formatting on IBM systems
http://www.garlic.com/~lynn/2001.html#52 Review of Steve McConnell's AFTER THE GOLD RUSH
http://www.garlic.com/~lynn/2001l.html#24 mainframe question
http://www.garlic.com/~lynn/2003n.html#34 Macros and base register question
http://www.garlic.com/~lynn/2004d.html#21 REXX still going strong after 25 years
http://www.garlic.com/~lynn/2005e.html#52 Where should the type information be?
http://www.garlic.com/~lynn/2006e.html#32 transputers again was: The demise of Commodore
http://www.garlic.com/~lynn/2006p.html#1 Greatest Software Ever Written?
http://www.garlic.com/~lynn/2006t.html#9 32 or even 64 registers for x86-64?
http://www.garlic.com/~lynn/2006u.html#31 To RISC or not to RISC
http://www.garlic.com/~lynn/2007n.html#64 IBM System/360 DOS still going strong as Z/VSE
for additional topic drift ... i had been talking to one of the people
(that had been at los gatos vlsi lab) responsible for the 370 pascal
compiler (was used for chip tools, and eventually become vs/pascal on
both 370 and rs/6000) about doing a c-language front-end. before effort
got very far, he left and joined a company over in santa cruz.
not long afterwards, when acis was looking at doing a product porting
BSD to 370, they were looking around for a 370 c-compiler, i suggested
the company he had joined. before the BSD port was released for 370
... the effort was retargeted to pc/rt (which shipped as AOS and
required the company to do a romp backend in place of 370 backend).
various collected posts mentioning 801, risc, romp, rios, pl.8, cp.r, fort
knox, power, power/pc, etc
http://www.garlic.com/~lynn/subtopic.html#801
misc. past posts mentioning the company/compiler used for AOS
http://www.garlic.com/~lynn/2000e.html#20 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2002n.html#66 Mainframe Spreadsheets - 1980's History
http://www.garlic.com/~lynn/2002q.html#19 Beyond 8+3
http://www.garlic.com/~lynn/2003h.html#52 Question about Unix "heritage"
http://www.garlic.com/~lynn/2004d.html#71 What terminology reflects the "first" computer language ?
http://www.garlic.com/~lynn/2004f.html#42 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004n.html#30 First single chip 32-bit microprocessor
http://www.garlic.com/~lynn/2004q.html#35 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2004q.html#38 CAS and LL/SC
http://www.garlic.com/~lynn/2004q.html#39 CAS and LL/SC
http://www.garlic.com/~lynn/2004q.html#61 will there every be another commerically signficant new ISA?
http://www.garlic.com/~lynn/2005b.html#14 something like a CTC on a PC
http://www.garlic.com/~lynn/2005e.html#0 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005e.html#1 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005s.html#33 Power5 and Cell, new issue of IBM Journal of R&D
http://www.garlic.com/~lynn/2006b.html#8 Free to good home: IBM RT UNIX
http://www.garlic.com/~lynn/2007j.html#14 Newbie question on table design
Anne & Lynn Wheeler
re:
http://www.garlic.com/~lynn/2007p.html#48 Translation of IBM Basic Assembler to C?
for total other topic drift ... one of the people from the science
center
http://www.garlic.com/~lynn/subtopic.html#545tech
responsible for the implementation used in the internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet
many years later was working with one of the major real-time systems
implementated in C-language and thot he noticed something
familar. Checking the core monitor/dispatching routine ... it appeared
to be a hand translation from 370 assembler to C ... of the equivalent
routine from the internal network implementation ... down to preserving
all the original statement comment fields.
Frank McCoy
>Does anyone know of an automated method for doing this? Maybe a
>commercial service?
You don't *have* to, "translate" assembly-code for most C compilers.
There's usually an instruction or macro that tells the compiler to
interpret the following code as assembly-language; and a corresponding
instruction/macro to revert back to C.
You can intermix the two and use defines for either one.
Just make sure the calls between the two follow the defined protocols.
In my old Borlund "Turbo C" reference, for example, you use the "asm"
statement to do "inline assembly".
So (taking it straight from the book) you might code the "min" routine
that returns the smaller of two values like this:
int min(int V1, int V2)
{
asm MOV AX,V1
asm CMP AX,V2
asm JLE minexit
asm MOV AS,V2
minexit:
return(_AX);
}
It would be a rather trivial editing excercise to preceed all the
assembly-instruction-codes with "asm".
--
_____
/ ' / ™
,-/-, __ __. ____ /_
(_/ / (_(_/|_/ / <_/ <_
Tris Orendorff
news:3dm2g3t68bid5013k...@4ax.com:
> In alt.folklore.computers Howard S Shubs <how...@shubs.net> wrote:
>
>>Does anyone know of an automated method for doing this? Maybe a
>>commercial service?
>
> You don't *have* to, "translate" assembly-code for most C compilers.
> There's usually an instruction or macro that tells the compiler to
> interpret the following code as assembly-language; and a corresponding
> instruction/macro to revert back to C.
>
> You can intermix the two and use defines for either one.
> Just make sure the calls between the two follow the defined protocols.
>
> In my old Borlund "Turbo C" reference, for example, you use the "asm"
> statement to do "inline assembly".
Sorry, but IBM Basic Assembler is for IBM 360/370 machines, not Intel x86 micros.
--
Tris Orendorff
[ Anyone naming their child should spend a few minutes checking rhyming slang and dodgy sounding
names. Brad and Angelina failed to do this when naming their kid Shiloh Pitt. At some point, someone at
school is going to spoonerise her name.
Craig Stark]
Walter Bushell
Frank McCoy <mcc...@millcomm.com> wrote:
Yes, but that is not portable.
jmfb...@aol.com
I had read the query as tranlating it into the ASCII C rendition
of source code, not the EXE file.
/BAH
Anne & Lynn Wheeler
topic drift and x-over from
http://www.garlic.com/~lynn/2007p.html#54 Industry Standard Time To Analyze A Line Of Code
the pli program i wrote in the early 70s to analyze assembler listings
created an abstract representation of each instruction and things like
condition code, etc. Then when trying to represent the assembler as
(pli/pascal like) psuedo code ... there were attempts to do if/then/else
and do/while representations from assembler code sequences.
for some assembler code this worked fairly straight-forward ... but
there were cp67 and vm370 kernel routines that had fairly
straight-forward assembler code sequences ... although quite dense with
various condition code setting instructions followed with branch
conditions ... would have extremely complex and convoluted translated
psuedo code (attempting to use if/then/else, do/while, etc
representation). One such, fairly short and very straight-forward
test/branch assembler sequence translated into nested if/then/else more
than 20-deep.
old thread discussion some of the issue
http://www.garlic.com/~lynn/2006p.html#1 Greatest Software Ever Written?
http://www.garlic.com/~lynn/2006p.html#4 Greatest Software Ever Written?
Mickey
Assuming we are talking about the mainframe platform, the better
question would be "why would anyone WANT to do this?".
That having been said, I would not trust any process to convert BAL to
any flavor of C, the structure of the languages is simply to far
apart for any process to create anything better than REALLY BAD CODE.
Mickey
Charlie Gibbs
mic...@comcast.net (Mickey) writes:
> That having been said, I would not trust any process to convert BAL
> to any flavor of C, the structure of the languages is simply to far
> apart for any process to create anything better than REALLY BAD CODE.
Besides, there are plenty of people out there who are perfectly
capable of writing really bad C code on their own.
--
/~\ cgi...@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!
jmfb...@aol.com
Mickey <mic...@comcast.net> wrote:
>On Oct 1, 9:19 am, Howard S Shubs <how...@shubs.net> wrote:
>> Does anyone know of an automated method for doing this? Maybe a
>> commercial service?
>>
>> --
>> While its true that "you can't fix stupid", apparently you
>> can package it up and sell it. -- fnorgby on TMBO
>
>Assuming we are talking about the mainframe platform, the better
>question would be "why would anyone WANT to do this?".
Generate a source listing in an HLL from assembly? Millions
of reasons. This is not a new task. People have been doing
this since I got started in the biz.
>
>That having been said, I would not trust any process to convert BAL to
>any flavor of C, the structure of the languages is simply to far
>apart for any process to create anything better than REALLY BAD CODE.
It's merely a reverse engineering job; instead of hardware, it
involves software. There used to be a few
disassemblers that did this. (Something tells me I'm using the
incorrect word for disassembler.)
/BAH
Morten Reistad
The toolchain for *n*x systems has a pretty explicit logical pipe of
[source control] | cpp | cc | as | ld > object
You always have access to the assembler; you can terminate the
chain before as with the -S option to cc/gcc;
$ gcc -S foo.c
$
will leave the assembly file foo.s .
Often useful to see what the compiler generates.
-- mrr
jmfb...@aol.com
I don't see how this reverses the process. Sorry, Howard. I guess
I misread your question since I seem to be the only one who
read it that way.
/BAH
Anne & Lynn Wheeler
> I don't see how this reverses the process. Sorry, Howard. I guess
> I misread your question since I seem to be the only one who
> read it that way.
assembler -> C question wasn't about reversing some process ... it was
about programs that were originally written in 360/370 assembler (take
programs wirtten in 360/370 assembler and attempt to create a C-language
equivalent).
this is similar, but different than reverse engineering applications that
take object/executable (originally written in C) and attempts to
recreate the original C language statements.
the original had been separately x-posted to both (at least?)
alt.folklore.computers and comp.lang.asm370 newsgroups (the thread in
comp.lang.asm370 has somewhat more discussion of the characteristics of
programming directly in 360/370 assembler, as well as there has been
improvement in assembler features over the last 40 yrs)
re:
http://www.garlic.com/~lynn/2007p.html#48 Translation of IBM Basic Assembler to C?
http://www.garlic.com/~lynn/2007p.html#51 Translation of IBM Basic Assembler to C?
http://www.garlic.com/~lynn/2007p.html#57 Translation of IBM Basic Assembler to C?
Howard S Shubs
Tris Orendorff <tr...@remove-me.cogeco.ca> wrote:
> Sorry, but IBM Basic Assembler is for IBM 360/370 machines, not Intel x86
> micros.
And it's even worse if trying to use it on an Alpha.
Howard S Shubs
> I had read the query as tranlating it into the ASCII C rendition
> of source code, not the EXE file.
That's because you understand plain English. Apparently some others
have issues there. :-D
We were quoted prices in the $35K+ range, so we're going to the docs and
reimplementing from scratch. It would have been nicer to be sure, but
we're going to use the docs and previous experience to fill in the
blanks for this project. Maybe that will be enough.
Howard S Shubs
jmfb...@aol.com wrote:
> I don't see how this reverses the process. Sorry, Howard. I guess
> I misread your question since I seem to be the only one who
> read it that way.
Nah, they're trying to avoid the question entirely. You're one of the
few who actually tried to answer it.
Guys, what part of the question is unclear? You have a number of
assumptions which are not backed up by the question, with the key one
being "IBM Basic Assembler is available on the target machine".
If that were the case, I'd not have asked the question, and Barb either
saw that right off the top, or simply figured that the question didn't
ask "how do I use BAL in C". This code is going to a VMS product
running on Alpha and Itanium. BAL is not an option for some reason. Is
that clearer?
Howard S Shubs
> Assuming we are talking about the mainframe platform, the better
> question would be "why would anyone WANT to do this?".
Very bad assumption.
> That having been said, I would not trust any process to convert BAL to
> any flavor of C, the structure of the languages is simply to far
> apart for any process to create anything better than REALLY BAD CODE.
It would have been a place to start for people who DON'T KNOW BAL, and
AREN'T INTERESTED in learning it.
Mickey
> In article <1191431489.487250.181...@r29g2000hsg.googlegroups.com>,
>
> Mickey <mick...@comcast.net> wrote:
> > Assuming we are talking about the mainframe platform, the better
> > question would be "why would anyone WANT to do this?".
>
> Very bad assumption.
>
> > That having been said, I would not trust any process to convert BAL to
> > any flavor of C, the structure of the languages is simply to far
> > apart for any process to create anything better than REALLY BAD CODE.
>
> It would have been a place to start for people who DON'T KNOW BAL, and
> AREN'T INTERESTED in learning it.
I'm confused... a place to start WHAT? Surely you do not expect people
to learn C by looking at the output of a code generator, do you?
Converting BAL code to anything other that BAL (such as F-ASM to H-ASM
or VSE to MVS) is virtually impossible. Then again, what do I know, I
only worked writing conversion tools for 15 years.
Mickey
Mickey
CBFalconer
> jmfb...@aol.com writes:
>
>> I don't see how this reverses the process. Sorry, Howard. I
>> guess I misread your question since I seem to be the only one
>> who read it that way.
>
> assembler -> C question wasn't about reversing some process ...
> it was about programs that were originally written in 360/370
> assembler (take programs wirtten in 360/370 assembler and attempt
> to create a C-language equivalent).
Dead easy. Compile the C code with gcc and the -c option.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com
Peter Flass
You start out with garbage, but at least garbage that works. From there
you can rewrite sections of it as needed.
Peter Flass
I can't believe it's "virtually impossible" as long as you rule out
self-modifying code. At worst you could model the entire machine state
with C structs, but you should be able to do a lot better than this.
I'd like to hear more from Lynn about his project.
CBFalconer
> Anne & Lynn Wheeler wrote:
>> jmfb...@aol.com writes:
>>
>>> I don't see how this reverses the process. Sorry, Howard. I
>>> guess I misread your question since I seem to be the only one
>>> who read it that way.
>>
>> assembler -> C question wasn't about reversing some process ...
>> it was about programs that were originally written in 360/370
>> assembler (take programs wirtten in 360/370 assembler and attempt
>> to create a C-language equivalent).
>
> Dead easy. Compile the C code with gcc and the -c option.
Goofed. I meant: "gcc -gstabs+ -Wa,-ahldn -c"
Lawrence Statton
> CBFalconer wrote:
> > Anne & Lynn Wheeler wrote:
> >> jmfb...@aol.com writes:
> >>
> >>> I don't see how this reverses the process. Sorry, Howard. I
> >>> guess I misread your question since I seem to be the only one
> >>> who read it that way.
> >>
> >> assembler -> C question wasn't about reversing some process ...
> >> it was about programs that were originally written in 360/370
> >> assembler (take programs wirtten in 360/370 assembler and attempt
> >> to create a C-language equivalent).
> >
> > Dead easy. Compile the C code with gcc and the -c option.
>
> Goofed. I meant: "gcc -gstabs+ -Wa,-ahldn -c"
>
Won't that do precisely the OPPOSITE of what the OP wants? I think
everyone knows how to convert C to assembly - it is the reverse
process that is mildly tricky.
--
Lawrence Statton - lawre...@abaluon.abaom s/aba/c/g
Computer software consists of only two components: ones and
zeros, in roughly equal proportions. All that is required is to
place them into the correct order.
jmfb...@aol.com
> jmfb...@aol.com wrote:
>
>> I had read the query as tranlating it into the ASCII C rendition
>> of source code, not the EXE file.
>
>That's because you understand plain English. Apparently some others
>have issues there. :-D
The project was a common thing in my line of work. Maybe noone
else worked in the same kind of place I did.
>
>We were quoted prices in the $35K+ range,
Good grief, my aunt Fanny. It sounds like they were planning
to modify the C compiler to take the machine language and
rewind it to the ASCII.
> so we're going to the docs and
>reimplementing from scratch.
That sounds like the only way to get a C source. Does it have
to be C?
> It would have been nicer to be sure, but
>we're going to use the docs and previous experience to fill in the
>blanks for this project. Maybe that will be enough.
It would be nice to be able to run side by side to make sure
that the runs are at least the "same"; we called it consistent.
It could be wrong but at least it's the same wrong.
There had to have been some code out there in the past that converted
BAL to something like FORTRAN. Is there any code that converts
FORTRAN to C?
You could do a two-stepper.
How long do you have to get this done? ;-)
/BAH
Mickey
Me too, as there are several issues I'd like to see the resolution
for. I coded IBM's DOS/VSE to MVS BAL converter, and even there, we
had issue that simply could not be handled by an automated tool.
Mickey
Howard S Shubs
jmfb...@aol.com wrote:
> That sounds like the only way to get a C source. Does it have
> to be C?
Nah, could be in FORTRAN too.
> It would be nice to be able to run side by side to make sure
> that the runs are at least the "same"; we called it consistent.
> It could be wrong but at least it's the same wrong.
Yes. We have test data and test answers. They should be sufficient,
but only if we can get our code to match them. For those who might
understand, I'm talking about the V25.0 MS-DRG grouper.
> There had to have been some code out there in the past that converted
> BAL to something like FORTRAN. Is there any code that converts
> FORTRAN to C?
>
> You could do a two-stepper.
Interesting idea. I think I'll look into that. If I can find a FORTRAN
solution, Certain People would be more pleased.
> How long do you have to get this done? ;-)
About a month. While the new grouper took effect on 1 October, our
system is for later data analysis so it wasn't needed right when the
change occurred. But it needs to be available soon.
Howard S Shubs
Anne & Lynn Wheeler <ly...@garlic.com> wrote:
> the original had been separately x-posted to both (at least?)
> alt.folklore.computers and comp.lang.asm370 newsgroups (the thread in
> comp.lang.asm370 has somewhat more discussion of the characteristics of
> programming directly in 360/370 assembler, as well as there has been
> improvement in assembler features over the last 40 yrs)
Yes, however after the query being taken (tounge in cheek?) as an insult
to BAL, I decided to ask here. I've also found that comp.lang.asm370 is
very low traffic.
Howard S Shubs
Lawrence Statton <yankee...@gmail.com> wrote:
> Won't that do precisely the OPPOSITE of what the OP wants? I think
> everyone knows how to convert C to assembly - it is the reverse
> process that is mildly tricky.
Some people really do have reading comprehension problems, Mr. Statton.
That, or they're just fucking with me. After all, the advice you get on
USENET is often worth what you pay for it. I'm just glad Barb is here.
:-)
jmfb...@aol.com
> jmfb...@aol.com wrote:
>
>> That sounds like the only way to get a C source. Does it have
>> to be C?
>
>Nah, could be in FORTRAN too.
>
>
>> It would be nice to be able to run side by side to make sure
>> that the runs are at least the "same"; we called it consistent.
>> It could be wrong but at least it's the same wrong.
>
>Yes. We have test data and test answers. They should be sufficient,
>but only if we can get our code to match them. For those who might
>understand, I'm talking about the V25.0 MS-DRG grouper.
<grin> It sounds like a fish product.
>
>
>> There had to have been some code out there in the past that converted
>> BAL to something like FORTRAN. Is there any code that converts
>> FORTRAN to C?
>>
>> You could do a two-stepper.
>
>Interesting idea. I think I'll look into that. If I can find a FORTRAN
>solution, Certain People would be more pleased.
Well, there is the wrinkle of Fortran no longer looking like FORTRAN.
>
>
>> How long do you have to get this done? ;-)
>
>About a month. While the new grouper took effect on 1 October, our
>system is for later data analysis so it wasn't needed right when the
>change occurred. But it needs to be available soon.
That ain't very long at all. Good luck.
/BAH
jmfb...@aol.com
> Lawrence Statton <yankee...@gmail.com> wrote:
>
>> Won't that do precisely the OPPOSITE of what the OP wants? I think
>> everyone knows how to convert C to assembly - it is the reverse
>> process that is mildly tricky.
>
>Some people really do have reading comprehension problems, Mr. Statton.
>That, or they're just fucking with me. After all, the advice you get on
>USENET is often worth what you pay for it. I'm just glad Barb is here.
>:-)
Thanks [blushing emoticon here] I'm still thinking about it. Would
RPG or COBOL be a better fit?
/BAH
Morten Reistad
>Good grief, my aunt Fanny. It sounds like they were planning
>to modify the C compiler to take the machine language and
>rewind it to the ASCII.
>
>> so we're going to the docs and
>>reimplementing from scratch.
>
>That sounds like the only way to get a C source. Does it have
>to be C?
The thing you would be asking for is an instruction-converter to
another language or architecture. It has been done with the Vax->alpha
and with the Transmeta toolchest.
It would be far easier to do with a symbolic assemble though.
>> It would have been nicer to be sure, but
>>we're going to use the docs and previous experience to fill in the
>>blanks for this project. Maybe that will be enough.
>
>It would be nice to be able to run side by side to make sure
>that the runs are at least the "same"; we called it consistent.
>It could be wrong but at least it's the same wrong.
>
>There had to have been some code out there in the past that converted
>BAL to something like FORTRAN. Is there any code that converts
>FORTRAN to C?
f2c. It has some issues with linkage scope for fortran modules though.
But it works far better than ratfor.
-- mrr
Howard S Shubs
jmfb...@aol.com wrote:
> Thanks [blushing emoticon here] I'm still thinking about it. Would
> RPG or COBOL be a better fit?
We have BASIC (which I don't want to use), FORTRAN, and C.
Howard S Shubs
jmfb...@aol.com wrote:
> <grin> It sounds like a fish product.
Yes, it's fishy alright, but then it's a U.S. Government thing...
> Well, there is the wrinkle of Fortran no longer looking like FORTRAN.
It's nice to have memory allocation and such features.
> That ain't very long at all. Good luck.
Yeah, it's a problem.
jmfb...@aol.com
Morten Reistad <fi...@last.name> wrote:
>In article <fe51o0$8qk...@s893.apx1.sbo.ma.dialup.rcn.com>,
> <jmfb...@aol.com> wrote:
>>In article <howard-147E8C....@news.supernews.com>,
>> Howard S Shubs <how...@shubs.net> wrote:
>
>>Good grief, my aunt Fanny. It sounds like they were planning
>>to modify the C compiler to take the machine language and
>>rewind it to the ASCII.
>>
>>> so we're going to the docs and
>>>reimplementing from scratch.
>>
>>That sounds like the only way to get a C source. Does it have
>>to be C?
>
>The thing you would be asking for is an instruction-converter to
>another language or architecture. It has been done with the Vax->alpha
>and with the Transmeta toolchest.
It wouldn't be too difficult to get from one machine language to
the next. The same problem exists in getting from the machine
language to an HLL.
Since Howard only has one month, it's faster to simply do
the whole thing from scratch. But I think I'd pick the
FORTRAN, not C.
>
>It would be far easier to do with a symbolic assemble though.
hUH? Maybe I'm suffering from my DEC bias but I don't see
going from machine language to symbolic is difficult.
>
>>> It would have been nicer to be sure, but
>>>we're going to use the docs and previous experience to fill in the
>>>blanks for this project. Maybe that will be enough.
>>
>>It would be nice to be able to run side by side to make sure
>>that the runs are at least the "same"; we called it consistent.
>>It could be wrong but at least it's the same wrong.
>>
>>There had to have been some code out there in the past that converted
>>BAL to something like FORTRAN. Is there any code that converts
>>FORTRAN to C?
>
>f2c. It has some issues with linkage scope for fortran modules though.
Personally, I'd stop the conversion at FORTRAN and not go to C.
>
>But it works far better than ratfor.
It's an interesting problem to solve. :-)
/BAH
Anne & Lynn Wheeler
> Me too, as there are several issues I'd like to see the resolution
> for. I coded IBM's DOS/VSE to MVS BAL converter, and even there, we
> had issue that simply could not be handled by an automated tool.
re:
http://www.garlic.com/~lynn/2007p.html#48 Translation of IBM Basic Assembler to C?
http://www.garlic.com/~lynn/2007p.html#51 Translation of IBM Basic Assembler to C?
http://www.garlic.com/~lynn/2007p.html#57 Translation of IBM Basic Assembler to C?
http://www.garlic.com/~lynn/2007p.html#59 Translation of IBM Basic Assembler to C?
the application started out trying to capture and represent possible
assembler code path execution. i found i was "shooting" a lot of system
failures involving incorrect register contents ... typically anomolous
code path not initializing the register. attempts to provide psuedo-code
representation was somewhat an after thot. i was mainly using it against
kernel code that had been written with relatively consistent coding
guidelines ... but there were a number of assembler coding possibilities
that the application just had to flag and punt ... requiring human
assistance to resolve. i did some examples of source updates that tried
to demonstrate helping with automated analysis as well as helping with
human understandability.
the application also came up flagging some code segments that were
likely "dead" code ... not having any obvious code path connectivity
... as well as flagging possible code path sequences resulting in "used"
before "set" registers.
the other characteristic already mentioned was that there was some
kernel assembler code sequences that were dense test/conditional-branch
coding sequences ... that appeared relatively understandable in
assembler but became quite convoluted when attempting to represent
in higher level psuedo-code if/then/else, do/while, etc. previously
referenced thread that discussed this in a little more detail
http://www.garlic.com/~lynn/2006p.html#1 Greatest Software Ever Written?
http://www.garlic.com/~lynn/2006p.html#4 Greatest Software Ever Written?
later, somewhat as an early demonstration of the power of REX(X) i did
a kernel debugger tool implemented in REX(X). the "demonstation" part
was to effectively create a "replacement" for an existing kernel
debugging tool ... written all in assembler (was something like
80kbytes of machine code). The demonstration was to take half-time
over three months, and achieve 10 times the function at the same
time being 10 times faster (some coding tricks since REX(X) was
purely interpreted compared to the assembled implemention).
misc. past posts
http://www.garlic.com/~lynn/subtopic.html#dumprx
the overlap between this and the earlier application was at any
particular failure ... what indications were available to reconstruct
(aka failure forensics) the code flow leading up to the failure
for some reason, while the failure analysis application was used
extensively, world-wide within the corporation ... couldn't quite get it
to the point of releasing it to customers.
the assembler application was also looked at somewhat in conjunction
with some of the fort knox activities. one of the first uses targeted
for 801/risc processors was an effort to replace a large number of
internal microprocessors developed for all sorts of purposes with common
microprossesors ... including several that were used in low and
mid-range 370s ... aka core engine used for emulating 370 instruction.
one of the possible "added" features ... in addition to the
straight-forward instruction emulation ... was there the possibility of
dynamically doing high-use code path recognition ... and doing
just-in-time code snippet conversion (aka analyzing 370 code snippet
sequences and dynamically converting to 801 instruction sequences).
This was originally targeted that the 4331/4341 followon processors
(i.e. 4361 and 4381) would use 801 as core platform microengine. turns
out i helped with the justification killing this effort ...
i.e. silicon was becoming dense enuf that it was becoming possible to
implement much of 370 directly silicon ... starting the move away from
the emulation based paradigm. misc. posts mentioning risc, romp. rios,
fort knox and other 801 activities
http://www.garlic.com/~lynn/subtopic.html#801
this dynamic, just-in-time (JIT) capability would have been somewhat
equivalent to the ECPS effort ... but done dynamically on the fly
... rather than static, recent post mentioning/discussing ECPS
http://www.garlic.com/~lynn/2007p.html#8 what does xp do when system is copying
http://www.garlic.com/~lynn/2007p.html#36 Writing 23FDs
another project in the 80s, involved looking at the tss/370 kernel as
core platform for various operating system efforts. the vm370 kernel had
gotten quite complex with lots of spaghetti code from the contributions
of hundreds of different people having worked on it over a period of
years. by comparison ... after tss/360 was decommited, the tss/360 (and
later tss/370) kernel became fairly tightly coded supported by small
number of dedicated people. vm370 had been loosly its original
micro-kernel implementation ... somewhat as more and more people with
"operating system" background thought it to be the place to throw in
everything, including the kitchen sink.
there was a proposal to look at possibly doing something that returned
the implementation to a micro-kernel. one of the suggestions was to
leveraging the existing tss/370 kernel code as a starting point (as
opposed to starting completely from scratch). this was in the period
where the tss/370 kernel had undergone the exercise that used a stripped
down version with unix api layered ontop for bell. So there was look at
comparing the overall sizes and complexity of the existing vm370 kernel
code base vis-a-vis the tss/370 kernel code base. I also used my pli
application to try and create representation of the code path complexity
of the vm370 kernel code vis-a-vis the tss/370 kernel code. The analysis
program ran against the assembler listing output which would also
attempt to include the instruction "displacement" fields to help resolve
ambiquity. One of the differences between the os/360 genre of assemblers
and the tss/370 assembler was that the tss/370 assembler included a
space identifier for each displacement field (i.e. explicitly
identifying which csect or dsect a displacement applied to). in os/360
it remained ambiquous which possible space the assembler was taking a
symbolic reference from (aka to resolve that information would have
required modifying the assembler application to preserve the
information).
old post/thread discussion the complexity investigation
comparing tss and vm
http://www.garlic.com/~lynn/2001m.html#53 TSS/360
Charles Richmond
> In article <m3d4vvm...@garlic.com>,
> Anne & Lynn Wheeler <ly...@garlic.com> wrote:
>
>> the original had been separately x-posted to both (at least?)
>> alt.folklore.computers and comp.lang.asm370 newsgroups (the thread in
>> comp.lang.asm370 has somewhat more discussion of the characteristics of
>> programming directly in 360/370 assembler, as well as there has been
>> improvement in assembler features over the last 40 yrs)
>
> Yes, however after the query being taken (tounge in cheek?) as an insult
> to BAL, I decided to ask here. I've also found that comp.lang.asm370 is
> very low traffic.
>
So you lost your "nickel" in comp.lang.asm370, but you
are looking for it here because the light is better. ;-)
--
+----------------------------------------------------------------+
| Charles and Francis Richmond richmond at plano dot net |
+----------------------------------------------------------------+
Mickey
> Mickey <mick...@comcast.net> writes:
> > Me too, as there are several issues I'd like to see the resolution
> > for. I coded IBM's DOS/VSE to MVS BAL converter, and even there, we
> > had issue that simply could not be handled by an automated tool.
>
>
> the application started out trying to capture and represent possible
> assembler code path execution. i found i was "shooting" a lot of system
> failures involving incorrect register contents ... typically anomolous
> code path not initializing the register. attempts to provide psuedo-code
> representation was somewhat an after thot. i was mainly using it against
> kernel code that had been written with relatively consistent coding
> guidelines ... but there were a number of assembler coding possibilities
> that the application just had to flag and punt ... requiring human
> assistance to resolve.
This was EXACTLY the point I was making. If one cannot convert 100% of
VSE BAL to MVS BAL without human intervention, the path to C will be
FAR more problematic. The basics of the VSE to MVS conversion was that
we were able to convert 95% of the code, but the 5% that remained took
95% of the time to9 x :)
Mickey
Anne & Lynn Wheeler
> This was EXACTLY the point I was making. If one cannot convert 100% of
> VSE BAL to MVS BAL without human intervention, the path to C will be
> FAR more problematic. The basics of the VSE to MVS conversion was that
> we were able to convert 95% of the code, but the 5% that remained took
> 95% of the time to9 x :)
note, i believe that some of the newer generation of 370 emulators
running on i86 platforms do have the capability of performing 370 code
snippet dynamic JIT-translation to i86 (however, there may be all sort
of caveats, restrictions, and limitations)
re:
http://www.garlic.com/~lynn/2007p.html#48 Translation of IBM Basic Assembler to C?
http://www.garlic.com/~lynn/2007p.html#51 Translation of IBM Basic Assembler to C?
http://www.garlic.com/~lynn/2007p.html#57 Translation of IBM Basic Assembler to C?
http://www.garlic.com/~lynn/2007p.html#59 Translation of IBM Basic Assembler to C?
http://www.garlic.com/~lynn/2007p.html#65 Translation of IBM Basic Assembler to C?
Mickey
> Mickey <mick...@comcast.net> writes:
> > This was EXACTLY the point I was making. If one cannot convert 100% of
> > VSE BAL to MVS BAL without human intervention, the path to C will be
> > FAR more problematic. The basics of the VSE to MVS conversion was that
> > we were able to convert 95% of the code, but the 5% that remained took
> > 95% of the time to9 x :)
>
> note, i believe that some of the newer generation of 370 emulators
> running on i86 platforms do have the capability of performing 370 code
> snippet dynamic JIT-translation to i86 (however, there may be all sort
> of caveats, restrictions, and limitations)
>
The first thing that comes to mine is GETMAIN.
Mickey
Peter Flass
FORTRAN to PL/I exists.
Frank McCoy
I've done Pascal to C, in the past.
--
_____
/ ' / ™
,-/-, __ __. ____ /_
(_/ / (_(_/|_/ / <_/ <_
ArarghMai...@not.at.arargh.com
wrote:
<snip>
>
>I've done Pascal to C, in the past.
By hand, or by program?
I've done COBOL to Basic, with a program, and C, Pascal & Assembler to
Basic, by hand.
Gets boring after a while. :-)
--
ArarghMail710 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html
To reply by email, remove the extra stuff from the reply address.
Frank McCoy
>On Fri, 05 Oct 2007 16:56:17 -0500, Frank McCoy <mcc...@millcomm.com>
>wrote:
>
><snip>
>>
>>I've done Pascal to C, in the past.
>
>By hand, or by program?
>
By program.
It was a BEAR.
>I've done COBOL to Basic, with a program, and C, Pascal & Assembler to
>Basic, by hand.
>
>Gets boring after a while. :-)
Necessary, in this case, to keep three sets of programs 100% compatible.
If one got changed, the other three got changed. One source, in Pascal.
ArarghMai...@not.at.arargh.com
wrote:
>In alt.folklore.computers ArarghMai...@NOT.AT.Arargh.com wrote:
>
>>On Fri, 05 Oct 2007 16:56:17 -0500, Frank McCoy <mcc...@millcomm.com>
>>wrote:
>>
>><snip>
>>>
>>>I've done Pascal to C, in the past.
>>
>>By hand, or by program?
>>
>By program.
>It was a BEAR.
I can imagine.
There are things you can do in Pascal, that you can't do in C.
>
>>I've done COBOL to Basic, with a program, and C, Pascal & Assembler to
>>Basic, by hand.
>>
>>Gets boring after a while. :-)
>
>Necessary, in this case, to keep three sets of programs 100% compatible.
>If one got changed, the other three got changed. One source, in Pascal.
Hmmm. 1+3 ?
Gerard Schildberger
|> Frank McCoy wrote:
|>> ArarghMail710 wrote:
|>>> Frank McCoy wrote:
|>> <snip>
|>>>I've done Pascal to C, in the past.
|>>By hand, or by program?
|>By program.
|>It was a BEAR.
| I can imagine.
| There are things you can do in Pascal, that you can't do in C.
Oh, oh, now you've slapped someone with a glove. (My daddy can
beat your daddy...) ________________________________________Gerard S.
Frank McCoy
>On Fri, 05 Oct 2007 19:31:47 -0500, Frank McCoy <mcc...@millcomm.com>
>wrote:
>
>>In alt.folklore.computers ArarghMai...@NOT.AT.Arargh.com wrote:
>>
>>>On Fri, 05 Oct 2007 16:56:17 -0500, Frank McCoy <mcc...@millcomm.com>
>>>wrote:
>>>
>>><snip>
>>>>
>>>>I've done Pascal to C, in the past.
>>>
>>>By hand, or by program?
>>>
>>By program.
>>It was a BEAR.
>I can imagine.
>There are things you can do in Pascal, that you can't do in C.
>
Huh?
I found it the other way around.
>>
>>>I've done COBOL to Basic, with a program, and C, Pascal & Assembler to
>>>Basic, by hand.
>>>
>>>Gets boring after a while. :-)
>>
>>Necessary, in this case, to keep three sets of programs 100% compatible.
>>If one got changed, the other three got changed. One source, in Pascal.
>Hmmm. 1+3 ?
One copy (the master) in Pascal on an Intel system.
One copy (secondary) in HP-C on an HP system.
One copy (tertiary) in Borlund-C on a PC under DOS.
The main translation was done using shell-scripts on the HP system under
Unix. The *hard* translation parts were done using the Xedit variation
of vi, again under Unix, but using a script I wrote for Xedit.
I'm not quite sure that's exactly "a program"; but I'd transfer the data
from the Intel system to the HP system using the Xmodem protocol (for
which I wrote a program on the HP system and used an existing program on
the Intel side) to send the program source over a serial link between
the two. Then I'd invoke my shell-script to translate from Intel-Pascal
to HP-C, compile the thing to make sure no mistakes occurred; then run
another (*much* smaller) shell-script to make the very minor changes
from HP-C to Borlund-C. Those last changes were mainly things like DOS
hooks and file-handling. The main differences between the three
compilers were all handled by careful use of personally defined variable
types in the three languages and relatively straightforward conversions
of upper/lower-case and use of semicolons to end function-calls.
Oh yeah: And *lots* of IF statements in the source code.
Frank McCoy
wrote:
>| ArarghMail710 wrote:
>|> Frank McCoy wrote:
>|>> ArarghMail710 wrote:
>|>>> Frank McCoy wrote:
>
>|>> <snip>
>
>|>>>I've done Pascal to C, in the past.
>
>|>>By hand, or by program?
>
>|>By program.
>|>It was a BEAR.
>
>| I can imagine.
>| There are things you can do in Pascal, that you can't do in C.
>
>Oh, oh, now you've slapped someone with a glove. (My daddy can
>beat your daddy...) ________________________________________Gerard S.
>
Yup. Never found a single thing I could do in Pascal I couldn't do in
C. The reverse, is not so true. C really *is* a language that allows
you to shoot yourself in the foot very thoroughly ... Almost as much as
Assembly-language will.
That's one reason why my source was in Pascal, not vice-versa.
ArarghMai...@not.at.arargh.com
<Gera...@rrt.net> wrote:
>| ArarghMail710 wrote:
>| I can imagine.
>| There are things you can do in Pascal, that you can't do in C.
>
>Oh, oh, now you've slapped someone with a glove. (My daddy can
>beat your daddy...) ________________________________________Gerard S.
Your point being??
Just offhand I can think of two things you can do in Pascal, one of
which you can't do in C, and the other you can't do directly in C.
And, I haven't worked with Pascal in maybe 20 years. Or C for that
matter.
Can't do either in Basic, either. :-)
ArarghMai...@not.at.arargh.com
wrote:
>In alt.folklore.computers ArarghMai...@NOT.AT.Arargh.com wrote:
>
>>On Fri, 05 Oct 2007 19:31:47 -0500, Frank McCoy <mcc...@millcomm.com>
>>wrote:
>>
>>>In alt.folklore.computers ArarghMai...@NOT.AT.Arargh.com wrote:
>>>
>>>>On Fri, 05 Oct 2007 16:56:17 -0500, Frank McCoy <mcc...@millcomm.com>
>>>>wrote:
>>>>
>>>><snip>
>>>>>
>>>>>I've done Pascal to C, in the past.
>>>>
>>>>By hand, or by program?
>>>>
>>>By program.
>>>It was a BEAR.
>>I can imagine.
>>There are things you can do in Pascal, that you can't do in C.
>>
>Huh?
>I found it the other way around.
Procedure in a procedure?
AFAIK, you can't do that in C.
<snip>
Frank McCoy
>On Fri, 05 Oct 2007 22:39:03 -0500, Frank McCoy <mcc...@millcomm.com>
>wrote:
>
>>In alt.folklore.computers ArarghMai...@NOT.AT.Arargh.com wrote:
>>
>>>On Fri, 05 Oct 2007 19:31:47 -0500, Frank McCoy <mcc...@millcomm.com>
>>>wrote:
>>>
>>>>In alt.folklore.computers ArarghMai...@NOT.AT.Arargh.com wrote:
>>>>
>>>>>On Fri, 05 Oct 2007 16:56:17 -0500, Frank McCoy <mcc...@millcomm.com>
>>>>>wrote:
>>>>>
>>>>><snip>
>>>>>>
>>>>>>I've done Pascal to C, in the past.
>>>>>
>>>>>By hand, or by program?
>>>>>
>>>>By program.
>>>>It was a BEAR.
>>>I can imagine.
>>>There are things you can do in Pascal, that you can't do in C.
>>>
>>Huh?
>>I found it the other way around.
>
>Procedure in a procedure?
>
>AFAIK, you can't do that in C.
>
A. Who says you can't?
B. I've seen it DONE; but never could figure out WHY.
ArarghMai...@not.at.arargh.com
wrote:
>In alt.folklore.computers ArarghMai...@NOT.AT.Arargh.com wrote:
>
>>On Fri, 05 Oct 2007 22:39:03 -0500, Frank McCoy <mcc...@millcomm.com>
>>wrote:
>>
>>>In alt.folklore.computers ArarghMai...@NOT.AT.Arargh.com wrote:
>>>
>>>>On Fri, 05 Oct 2007 19:31:47 -0500, Frank McCoy <mcc...@millcomm.com>
>>>>wrote:
>>>>
>>>>>In alt.folklore.computers ArarghMai...@NOT.AT.Arargh.com wrote:
>>>>>
>>>>>>On Fri, 05 Oct 2007 16:56:17 -0500, Frank McCoy <mcc...@millcomm.com>
>>>>>>wrote:
>>>>>>
>>>>>><snip>
>>>>>>>
>>>>>>>I've done Pascal to C, in the past.
>>>>>>
>>>>>>By hand, or by program?
>>>>>>
>>>>>By program.
>>>>>It was a BEAR.
>>>>I can imagine.
>>>>There are things you can do in Pascal, that you can't do in C.
>>>>
>>>Huh?
>>>I found it the other way around.
>>
>>Procedure in a procedure?
>>
>>AFAIK, you can't do that in C.
>>
>A. Who says you can't?
K&R Version 2: (although I read it in Version 1)
<quote>
4.8 Block Structure
C is not a block-structured language in the sense of Pascal or similar
languages, because functions may not be defined within other
functions.
</quote>
But, supposedly GCC allows it, anyway.
>B. I've seen it DONE; but never could figure out WHY.
Pascal is the only language that I know about that allows it. I also
have never figured out what it is good for, except to make for
confusing programs.
A LONG time ago, 1985 maybe?, I translated the Pascal-S compiler
source to Basic. Drove me crazy because with all the recursive calls,
(with the Basic in question I had to use gosubs) it exceeded the gosub
limit of 8. I had to decompile the basic interpreter and with a
listing of an earlier version had to hack the gosub limit up to 24 or
so, IIRC. Got it working, though. :-)
jmfb...@aol.com
Charles Richmond <fri...@tx.rr.com> wrote:
>Howard S Shubs wrote:
>> In article <m3d4vvm...@garlic.com>,
>> Anne & Lynn Wheeler <ly...@garlic.com> wrote:
>>
>>> the original had been separately x-posted to both (at least?)
>>> alt.folklore.computers and comp.lang.asm370 newsgroups (the thread in
>>> comp.lang.asm370 has somewhat more discussion of the characteristics of
>>> programming directly in 360/370 assembler, as well as there has been
>>> improvement in assembler features over the last 40 yrs)
>>
>> Yes, however after the query being taken (tounge in cheek?) as an insult
>> to BAL, I decided to ask here. I've also found that comp.lang.asm370 is
>> very low traffic.
>>
>
>So you lost your "nickel" in comp.lang.asm370, but you
>are looking for it here because the light is better. ;-)
Of course. :-) This newsgroup knows everything. It
doesn't have its head wedged where the sun don't shine.
/BAH
jmfb...@aol.com
Mickey <mic...@comcast.net> wrote:
>On Oct 5, 9:39 am, Anne & Lynn Wheeler <l...@garlic.com> wrote:
>> Mickey <mick...@comcast.net> writes:
>> > Me too, as there are several issues I'd like to see the resolution
>> > for. I coded IBM's DOS/VSE to MVS BAL converter, and even there, we
>> > had issue that simply could not be handled by an automated tool.
>>
>> re:http://www.garlic.com/~lynn/2007p.html#48Translation of IBM Basic
Assembler to C?http://www.garlic.com/~lynn/2007p.html#51Translation of IBM
Basic Assembler to C?http://www.garlic.com/~lynn/2007p.html#57Translation of
IBM Basic Assembler to C?http://www.garlic.com/~lynn/2007p.html#59Translation
of IBM Basic Assembler to C?
>>
>> the application started out trying to capture and represent possible
>> assembler code path execution. i found i was "shooting" a lot of system
>> failures involving incorrect register contents ... typically anomolous
>> code path not initializing the register. attempts to provide psuedo-code
>> representation was somewhat an after thot. i was mainly using it against
>> kernel code that had been written with relatively consistent coding
>> guidelines ... but there were a number of assembler coding possibilities
>> that the application just had to flag and punt ... requiring human
>> assistance to resolve.
>
>
>This was EXACTLY the point I was making. If one cannot convert 100% of
>VSE BAL to MVS BAL without human intervention,
All conversions require human intervention. The project doesn't
require this conversion to happen each and every time the final
sources are created. It's a one-time job.
>the path to C will be
>FAR more problematic. The basics of the VSE to MVS conversion was that
>we were able to convert 95% of the code, but the 5% that remained took
>95% of the time to9 x :)
That's why Howard is asking for a converter. He's got one month
to convert all the code. If he can get 95% done, then that 5%
could get done in a month, including testing...although my
workclock would require 48 hr/day to do this one. Howard must
have at least 5 people working.
This is also why starting from scratch is more manageable.
Sectors of code can be assigned/person rather than itty bitty
bits and pieces here and there.
/BAH
/BAH
Anne & Lynn Wheeler
> Yup. Never found a single thing I could do in Pascal I couldn't do in
> C. The reverse, is not so true. C really *is* a language that allows
> you to shoot yourself in the foot very thoroughly ... Almost as much as
> Assembly-language will.
for instance ... that nature of the pascal language contributed
significantly to avoiding writing code that would result in failures
related to lengths and/or buffers ... which is almost the inverse for C
language (it seems to go out of its way to encourage the writing of code
that results in length and buffer related failures) ... misc.
past posts mentioning the issue
http://www.garlic.com/~lynn/subintegrity.html#overflow
discussed before is that it isn't necessarily directly the C language
... but the whole environment related C language implementations.
somewhat earlier in this thread ...
http://www.garlic.com/~lynn/2007p.html#65 Translation of IBM Basic Assembler to C?
i mentioned doing extensive investigation into what caused failures in
the cp67 and vm370 kernels ... both completely implemented in 360/370
mainframe assembler. Even tho, the implementations were completely in
assembler ... there were actually extremely few buffer length related
coding errors. It wasn't that the assembler prevented it from happening
... but that the cp67 and vm370 coding conventions (which also occurs in
a broad range of mainframe assembler environments) were that there was
normally explicitly implemented lengths. The common C-language coding
conventions with implemently implemented lengths via null-terminated
strings seems to have greatly encouraged faulty coding conventions
resulting in very high percentage of failures related to length
processing.
a high percentage of cp67 and vm370 kernel failures were related to
register content management (frequently anomolous execution paths that
failed to establish register contents that were needed later) and
inadequate synchronization/serialization (things like dangling
references to dynamic storage that had been previously
de-allocated/released).
i've mentioned before that as part of releasing my (dynamic, adaptive)
resource manager,
http://www.garlic.com/~lynn/subtopic.html#fairshare
http://www.garlic.com/~lynn/subtopic.html#wsclock
i included a complete redo of the kernel serialization functions.
Part of this was that in preperation for releasing the resource
manager, had developed an automated benchmarking process
http://www.garlic.com/~lynn/subtopic.html#benchmark
the final benchmarking sequence perparing for the release of the
resource manager involved 2000 benchmarks that took three months elapsed
time to run. a lot of the benchmarks were involved in calibrated and
validating the dynamic adaptive resource manager operation across a
broad range of workloads and configurations. however, there were also an
extensive set of extreme stress benchmarking ... loads that were 10+
times what might be seen in any sort of live configuration. One
benchmark so heavily loaded the paging systems ... that the elapsed time
to service a page fault request was on the order of one second (because
the number of page requests in the queue was so large ... even
operating in excess of 300 page i/os per second).
Frank McCoy
AFAIK, both Borlund and Micro$hit C allow it.
I've seen it done in both.
Thinking about it:
It would probably be hard to write a good C compiler that did NOT allow
such a construct.
All C requires is that a function (or any variable type; and a function
is used like a variable) be defined before it gets used.
This can be done *inside* a function just as easily as outside; and as
far as the compiler goes there's no difference.
Hmmm ... Thinking about it though:
There *IS* a good reason for defining a function-within-a-function.
As I recall, somebody in a C class somewhere pointed it out to me.
A function defined within a function is *only* visible *to that
function*, just like any variable so-defined. So, if the internal
function is only needed inside a function and not by any other procedure
or function, then it makes good sense to define it there.
Actually, remembering:
You can define *any* function, not just within a function, but within
any set of braces:
int mix(int a, b)
{
int swap(*f,*g);
{
int temp;
temp = &f;
&f = &g;
&g = temp;
}
if (a > b)
swap(*a,*b);
return b - a;
}
Or ... something like that.
>A LONG time ago, 1985 maybe?, I translated the Pascal-S compiler
>source to Basic. Drove me crazy because with all the recursive calls,
>(with the Basic in question I had to use gosubs) it exceeded the gosub
>limit of 8. I had to decompile the basic interpreter and with a
>listing of an earlier version had to hack the gosub limit up to 24 or
>so, IIRC. Got it working, though. :-)
--
Peter Flass
This has been in PL/I since 1964. I can't imagine life without it.
Howard S Shubs
ArarghMai...@NOT.AT.Arargh.com wrote:
> Pascal is the only language that I know about that allows it. I also
> have never figured out what it is good for, except to make for
> confusing programs.
Fortran 90 too. It's useful for writing routines which don't appear in
the global symbol table but which can be invoked multiple times from one
(group of) routine.
Howard S Shubs
Frank McCoy <mcc...@millcomm.com> wrote:
> Yup. Never found a single thing I could do in Pascal I couldn't do in
> C. The reverse, is not so true. C really *is* a language that allows
> you to shoot yourself in the foot very thoroughly ... Almost as much as
> Assembly-language will.
How do you create sets in C as atomic data types without using explicit
bit maps?
Howard S Shubs
> This was EXACTLY the point I was making. If one cannot convert 100% of
> VSE BAL to MVS BAL without human intervention, the path to C will be
> FAR more problematic. The basics of the VSE to MVS conversion was that
> we were able to convert 95% of the code, but the 5% that remained took
> 95% of the time to9 x :)
The code involved here has no system-specific calls.
Howard S Shubs
jmfb...@aol.com wrote:
> That's why Howard is asking for a converter. He's got one month
> to convert all the code. If he can get 95% done, then that 5%
> could get done in a month, including testing...although my
> workclock would require 48 hr/day to do this one. Howard must
> have at least 5 people working.
Yes.
> This is also why starting from scratch is more manageable.
> Sectors of code can be assigned/person rather than itty bitty
> bits and pieces here and there.
All of that.
Frank McCoy
>In article <6r0eg3plhpkkomudh...@4ax.com>,
> Frank McCoy <mcc...@millcomm.com> wrote:
>
>> Yup. Never found a single thing I could do in Pascal I couldn't do in
>> C. The reverse, is not so true. C really *is* a language that allows
>> you to shoot yourself in the foot very thoroughly ... Almost as much as
>> Assembly-language will.
>
>How do you create sets in C as atomic data types without using explicit
>bit maps?
Not sure what you mean.
Give me a specific example, and I could probably give *you* a specific
example.
I mind once having a program create a set of data for an ECC program,
and then using an editor to make a fixed array of it for the end-result
ECC computing program written in C. That saved lots of time.
Walter Bushell
ArarghMai...@NOT.AT.Arargh.com wrote:
> There are things you can do in Pascal, that you can't do in C.
????
Well strictly speaking it's true that c has no IO. OTOH, standard Pascal
has no ability to reference an arbitrary file, based on input.
Frank McCoy
Not sure what you mean by "No IO".
I do remember that using the stdin and stdout was a real *PAIN*, because
I had to accept the default handling of characters; and Control-C or
other such characters just were *not* handled right, in my opinion.
This was *ALSO* very true of Pascal.
So ... I wrote my own character-handlers for both of them.
Actually, character, line, and all keyboard and terminal I/O.
To my notion, both stank like an outdoor privvy with no outhouse.
Howard S Shubs
Frank McCoy <mcc...@millcomm.com> wrote:
> Not sure what you mean.
> Give me a specific example, and I could probably give *you* a specific
> example.
I don't remember the Pascal syntax, but it has the ability to create a
set of items. An instance of the set can contain some of or all of or
none of the items.
Frank McCoy
>In article <iv5gg3dmad417nm4o...@4ax.com>,
> Frank McCoy <mcc...@millcomm.com> wrote:
>
>> Not sure what you mean.
>> Give me a specific example, and I could probably give *you* a specific
>> example.
>
>I don't remember the Pascal syntax, but it has the ability to create a
>set of items. An instance of the set can contain some of or all of or
>none of the items.
Ah yes ... Sets.
You *can* do the same thing in C.
However, you just have to create the set yourself; and then use standard
boolean logic on them. They aren't created *automatically* in C; but
you can do the same thing.
You just have to *understand* set and boolean logic a little deeper,
that's all. Most people who do set-logic in C do it clumsily; using
whole integers for each set; in comparison to Pascal which uses integer
values for the whole set. BUT you can do the same thing in C, if you
have a good idea of what you want to do, or if copying a program from
Pascal and have a good idea of how *that* does the machine-code.
Rather like doing the same thing in assembler.
Generally, if it CAN be done at all, it CAN be done in C.
That's because C is just glorified assembly-language with constructs.
(Or, at least that was what it was originally designed to be.)
C++, is a whole different piece of crap.
ArarghMai...@not.at.arargh.com
wrote:
>In alt.folklore.computers Howard S Shubs <how...@shubs.net> wrote:
>
>>In article <iv5gg3dmad417nm4o...@4ax.com>,
>> Frank McCoy <mcc...@millcomm.com> wrote:
>>
>>> Not sure what you mean.
>>> Give me a specific example, and I could probably give *you* a specific
>>> example.
>>
>>I don't remember the Pascal syntax, but it has the ability to create a
>>set of items. An instance of the set can contain some of or all of or
>>none of the items.
I don't remember the syntax, but something like:
const setname = {1...9,0}
and
if a in setname <whatever>
>Ah yes ... Sets.
>You *can* do the same thing in C.
>However, you just have to create the set yourself; and then use standard
>boolean logic on them. They aren't created *automatically* in C; but
>you can do the same thing.
Yes, that's what I was thinking of when I said you could do it, but
not directly.
<snip>
Peter Flass
A set can contaim zero or one copies of a member? It's trivial to do in
PL/I with a bit string (which can be any length).
Pete Fenelon
>> Not sure what you mean.
>> Give me a specific example, and I could probably give *you* a specific
>> example.
>
> I don't remember the Pascal syntax, but it has the ability to create a
> set of items. An instance of the set can contain some of or all of or
> none of the items.
>
True enough, but the maximum cardinality of sets is usually very
restricted in Pascal implementations. (ISTR that 'set of integer'
blows up most compilers; 'set of char' is about as much as you can
expect). Of course, since Standard Pascal is *mostly* used for toy
programming assignments this tends to lead to that archetypal 1980s
CS101-equivalent question involving implementing arbitrarily-sized
sets as an abstract data type....
Haven't touched Pascal in 20-odd years, and only ever did so when there
were no marks for doing it any other way ;)
pete
--
pe...@fenelon.com "how many clever men have called the sun a fool?"
Dave Wade
"Walter Bushell" <pr...@oanix.com> wrote in message
news:proto-595766....@news.panix.com...
If one were to be pedantict, in order to implement ANSI standard "C" you
must implement the "Standard C Library" which includes I/O. So whilst the
original K&R "C" did not include any I/O all the later standards do...
Frank McCoy
>In article <mqdqt4-...@fenelon.com>,
> Pete Fenelon <pe...@stratos.fenelon.com> wrote:
>
>> True enough, but the maximum cardinality of sets is usually very
>> restricted in Pascal implementations. (ISTR that 'set of integer'
>> blows up most compilers; 'set of char' is about as much as you can
>> expect). Of course, since Standard Pascal is *mostly* used for toy
>> programming assignments this tends to lead to that archetypal 1980s
>> CS101-equivalent question involving implementing arbitrarily-sized
>> sets as an abstract data type....
>
>Which is why Wirth created Modula2, yes?
That, and other problems with Pascal.
For some strange reason, Modula2, a much better designed language, never
had much acceptance. Even Ada, which came much later, did better.
Of course, Ada had/has the government behind it ....
Dennis Ritchie
"Pete Fenelon" <pe...@stratos.fenelon.com> wrote in message
news:mqdqt4-...@fenelon.com...
....
> True enough, but the maximum cardinality of sets is usually very
> restricted in Pascal implementations. (ISTR that 'set of integer'
> blows up most compilers; 'set of char' is about as much as you can
> expect). Of course, since Standard Pascal is *mostly* used for toy
> programming assignments this tends to lead to that archetypal 1980s
> CS101-equivalent question involving implementing arbitrarily-sized
> sets as an abstract data type....
The original Pascal had sets up to size 59 or perhaps 60, thanks
to the 60-bit word of the CDC 6600. They were clearly
just bitmaps. Later extensions did add to this, especially
when Pascal began to be used on minicomputers where
sets of max size 16 would have been pretty useless.
Dennis
Howard S Shubs
> True enough, but the maximum cardinality of sets is usually very
> restricted in Pascal implementations. (ISTR that 'set of integer'
> blows up most compilers; 'set of char' is about as much as you can
> expect). Of course, since Standard Pascal is *mostly* used for toy
> programming assignments this tends to lead to that archetypal 1980s
> CS101-equivalent question involving implementing arbitrarily-sized
> sets as an abstract data type....
Which is why Wirth created Modula2, yes?
--
Howard S Shubs
Frank McCoy <mcc...@millcomm.com> wrote:
> Ah yes ... Sets.
> You *can* do the same thing in C.
You *can* implement rocket systems in C, but that isn't a built-in
language function like sets are in Pascal.
Frank McCoy
>In article <aq9jg3h9m8bsvqa7m...@4ax.com>,
> Frank McCoy <mcc...@millcomm.com> wrote:
>
>> Ah yes ... Sets.
>> You *can* do the same thing in C.
>
>You *can* implement rocket systems in C, but that isn't a built-in
>language function like sets are in Pascal.
Remembering now:
The set-functions in Pascal were pretty useless just about every time I
found a need for such. As somebody else pointed-out, the limits on size
of such sets were pretty small and strict. The *only* case I ever used
such was in the set of characters; and I had *no* difficulty at all
doing the exact same thing in C.
If A in ('a'..'f' or 'A'..'F' or '0'..'9') then do ....
Don;t remember the exact syntax, but ....
Also, C++ does have set-logic.
Charles Richmond
At a PPoE, a female programmer who worked there... wrote an
allocation program for gasoline in the giant tanks at bulk
oil terminals. It was done in Turbo Pascal. She used sets
to keep up with days of the month for the allocation. For
instance, some allocation was every other day, so it was
(2,4,6,8,10,...,28,30). Some allocation was three times a
month on (10,20,30). Then she used the "in" operation with
the current day of the month (in a sequence of "if" statements),
to determine which allocations needed to be processed on
that day.
Since the sets only needed a max of 31 items, it worked great.
--
+----------------------------------------------------------------+
| Charles and Francis Richmond richmond at plano dot net |
+----------------------------------------------------------------+
Mickey
> In article <1191601705.932036.81...@y42g2000hsy.googlegroups.com>,
> Mickey <mick...@comcast.net> wrote:>On Oct 5, 9:39 am, Anne & Lynn Wheeler <l...@garlic.com> wrote:
> >> Mickey <mick...@comcast.net> writes:
> >> > Me too, as there are several issues I'd like to see the resolution
> >> > for. I coded IBM's DOS/VSE to MVS BAL converter, and even there, we
> >> > had issue that simply could not be handled by an automated tool.
>
>
> Assembler to C?http://www.garlic.com/~lynn/2007p.html#51Translationof IBM
> Basic Assembler to C?http://www.garlic.com/~lynn/2007p.html#57Translationof
> IBM Basic Assembler to C?http://www.garlic.com/~lynn/2007p.html#59Translation
> of IBM Basic Assembler to C?
>
>
>
> >> the application started out trying to capture and represent possible
> >> assembler code path execution. i found i was "shooting" a lot of system
> >> failures involving incorrect register contents ... typically anomolous
> >> code path not initializing the register. attempts to provide psuedo-code
> >> representation was somewhat an after thot. i was mainly using it against
> >> kernel code that had been written with relatively consistent coding
> >> guidelines ... but there were a number of assembler coding possibilities
> >> that the application just had to flag and punt ... requiring human
> >> assistance to resolve.
>
> >This was EXACTLY the point I was making. If one cannot convert 100% of
> >VSE BAL to MVS BAL without human intervention,
>
> All conversions require human intervention. The project doesn't
> require this conversion to happen each and every time the final
> sources are created. It's a one-time job.
My Cobol to Cobol/2 converted needs no human intervention, it will
even convert the OS Report Writer to native Cobol/2 code without help.
Mickey
Stan Barr
>In alt.folklore.computers Howard S Shubs <how...@shubs.net> wrote:
>>
>>Which is why Wirth created Modula2, yes?
>
>That, and other problems with Pascal.
>For some strange reason, Modula2, a much better designed language, never
>had much acceptance.
Neither did Oberon, a cleaned-up Modula designed with OO in mind.
I have a machine dedicated to it, the OS is written in Oberon.
--
Cheers,
Stan Barr stanb .at. dial .dot. pipex .dot. com
(Remove any digits from the addresses when mailing me.)
The future was never like this!
Frank McCoy
>On Mon, 08 Oct 2007 21:20:37 -0500, Frank McCoy <mcc...@millcomm.com> wrote:
>>In alt.folklore.computers Howard S Shubs <how...@shubs.net> wrote:
>>>
>>>Which is why Wirth created Modula2, yes?
>>
>>That, and other problems with Pascal.
>>For some strange reason, Modula2, a much better designed language, never
>>had much acceptance.
>
>Neither did Oberon, a cleaned-up Modula designed with OO in mind.
>
>I have a machine dedicated to it, the OS is written in Oberon.
I thought Modula-2 WAS designed with OO in mind. :-{
Pete Fenelon
>
Yes; I feel that Wirth paid his debt to society with Modula-2 and
Oberon. ;)
Frank McCoy
>Howard S Shubs <how...@shubs.net> wrote:
>> Which is why Wirth created Modula2, yes?
>>
>
>Yes; I feel that Wirth paid his debt to society with Modula-2 and
>Oberon. ;)
>
Only way too late, it seems. ;-{
Everybody knows of Pascal.
How many people have ever even *heard of* Oberon?
Roland Hutchinson
> In alt.folklore.computers Pete Fenelon <pe...@stratos.fenelon.com> wrote:
>
>>Howard S Shubs <how...@shubs.net> wrote:
>>> Which is why Wirth created Modula2, yes?
>>>
>>
>>Yes; I feel that Wirth paid his debt to society with Modula-2 and
>>Oberon. ;)
>>
> Only way too late, it seems. ;-{
> Everybody knows of Pascal.
> How many people have ever even *heard of* Oberon?
About as many as have heard of Mesa. Maybe more.
That's a lot of people, though they will not have learned about it in trade
school.
--
Roland Hutchinson Will play viola da gamba for food.
NB mail to my.spamtrap [at] verizon.net is heavily filtered to
remove spam. If your message looks like spam I may not see it.
Pete Fenelon
>
> About as many as have heard of Mesa. Maybe more.
>
> That's a lot of people, though they will not have learned about it in trade
> school.
Exposure to Mesa seems to be very closely tied to exposure to Xerox
hardware - I had a very good engineer working for me a few years ago who
praised the Mesa environment highly.
winston...@yahoo.com
> In alt.folklore.computers Howard S Shubs <how...@shubs.net> wrote:
>
> > Frank McCoy <mcc...@millcomm.com> wrote:
>
> >> Ah yes ... Sets.
> >> You *can* do the same thing in C.
>
> >You *can* implement rocket systems in C, but that isn't a built-in
> >language function like sets are in Pascal.
>
> Remembering now:
> The set-functions in Pascal were pretty useless just about every time I
> found a need for such. As somebody else pointed-out, the limits on size
> of such sets were pretty small and strict. The *only* case I ever used
> such was in the set of characters; and I had *no* difficulty at all
> doing the exact same thing in C.
>
> If A in ('a'..'f' or 'A'..'F' or '0'..'9') then do ....
> Don;t remember the exact syntax, but ....
>
> Also, C++ does have set-logic.
>
>
256 members, whereas UCSD Pascal allowed 4085. I know for a fact _my_
version of UCSD Pascal allowed 4096.
Don't know about Turbo/Borland...
Sets are awesome, much like lists in Lisp or Logo.
jmfb...@aol.com
31? Every other day needs more than 31 and leap year makes the
other years' lists wrong.
/BAH
jmfb...@aol.com
At some point, it will require tweaks. Howard's project was not
to do the code conversion each, and every, time the code is
compiled. AAMOF, if the project plan writers are sane, they
would make this item a non-goal.
/BAH
Charles Richmond
I guess I was *not* clear, BAH. This was *monthly* allocation.
Things repeated every month, *not* yearly.
Stan Barr
>In alt.folklore.computers sta...@dial.pipex.com (Stan Barr) wrote:
>>
>>Neither did Oberon, a cleaned-up Modula designed with OO in mind.
>>
>>I have a machine dedicated to it, the OS is written in Oberon.
>
>I thought Modula-2 WAS designed with OO in mind. :-{
OK, *more* in mind :-) Specifically, type extension*, missing from Modula-2,
was added.
* "...sorely needed missing part." "Programming in Oberon", Reiser & Wirth.
Stan Barr
>Everybody knows of Pascal.
>How many people have ever even *heard of* Oberon?
Which I think is a great pity, there's a lot of good concepts in there...
There are free compilers for many common platforms, and plenty of on-line
documentation so there's no excuse for not taking a look :-)
Frank McCoy
Frank McCoy
<winston...@yahoo.com> wrote:
4096 is small, for most uses I ever had.
Most sets I was interested in had membership on the order of several
millions at the least. Not hard to do with bits in an array though.
Mickey
> In article <1191938662.224063.47...@o3g2000hsb.googlegroups.com>,
Mine isn't a run time thing, it converts the Report Writer code into
native COBOL/2 or COBOL/370. You run it over a Report Writer program,
and from then on, you can use the standard COBOL compiler without
issue.
Mickey
Frank McCoy
wrote:
>Frank McCoy wrote:
>
>> In alt.folklore.computers Pete Fenelon <pe...@stratos.fenelon.com> wrote:
>>
>>>Howard S Shubs <how...@shubs.net> wrote:
>>>> Which is why Wirth created Modula2, yes?
>>>>
>>>
>>>Yes; I feel that Wirth paid his debt to society with Modula-2 and
>>>Oberon. ;)
>>>
>> Only way too late, it seems. ;-{
>> Everybody knows of Pascal.
>> How many people have ever even *heard of* Oberon?
>
>About as many as have heard of Mesa. Maybe more.
>
Mesa? That's a computer language?
>That's a lot of people, though they will not have learned about it in trade
>school.
--
Carl Lowenstein
<jmfb...@aol.com> wrote:
>In article <howard-147E8C....@news.supernews.com>,>>In article <fdvnfs$8qk...@s983.apx1.sbo.ma.dialup.rcn.com>,
>> jmfb...@aol.com wrote:
>>
>>> I had read the query as tranlating it into the ASCII C rendition
>>> of source code, not the EXE file.
>>
>>That's because you understand plain English. Apparently some others
>>have issues there. :-D
>
>The project was a common thing in my line of work. Maybe noone
>else worked in the same kind of place I did.
>
>>
>>We were quoted prices in the $35K+ range,
>
>Good grief, my aunt Fanny. It sounds like they were planning
>to modify the C compiler to take the machine language and
>rewind it to the ASCII.
>
>> so we're going to the docs and
>>reimplementing from scratch.
>
>That sounds like the only way to get a C source. Does it have
>to be C?
>
>> It would have been nicer to be sure, but
>>we're going to use the docs and previous experience to fill in the
>>blanks for this project. Maybe that will be enough.
>
>It would be nice to be able to run side by side to make sure
>that the runs are at least the "same"; we called it consistent.
>It could be wrong but at least it's the same wrong.
>
>There had to have been some code out there in the past that converted
>BAL to something like FORTRAN. Is there any code that converts
>FORTRAN to C?
>
>You could do a two-stepper.
Fortran to C has been around in Unix since 1990 or perhaps a bit earlier.
Called "f2c" in good 3-letter naming. I used it in a good-sized
translation project, carrying the S statistical package to NeXTstep.
carl
--
carl lowenstein marine physical lab, u.c. san diego
clowe...@ucsd.edu
Peter Flass
I used it to port the CP/M-80 compiler. The resulting C was pretty bad,
but it ran okay.
Dennis Ritchie
"Carl Lowenstein" <c...@deeptow.ucsd.edu> wrote in message
news:fejlf0$1d9t$1...@ihnp4.ucsd.edu...
....
> Fortran to C has been around in Unix since 1990 or perhaps a bit earlier.
> Called "f2c" in good 3-letter naming. I used it in a good-sized
> translation project, carrying the S statistical package to NeXTstep.
>
It was in 7th Edition Unix, and Stu Feldman's doc on it is dated
August 1978. Then it was just called f77.
Dennis
Carl Lowenstein
I was wondering about that as I wrote "1990 or perhaps a bit earlier".
My 7th Edition memories are slightly fuzzy, and the manual didn't remind
me sufficiently well.
Thanks for the reinforcement.
jmfb...@aol.com
So it was OK to have allocations done two days in a row if the
spec was every other day? Oct. 1, Oct. 3, ..., Oct 31, Nov.1.
Would that have been the schedule?
/BAH
Charles Richmond
> In article <470CF4A8...@tx.rr.com>,
> Charles Richmond <fri...@tx.rr.com> wrote:
>> jmfb...@aol.com wrote:
>>> In article <470B88EC...@tx.rr.com>,
>>> Charles Richmond <fri...@tx.rr.com> wrote:
>>>>
>>>>
>>>> At a PPoE, a female programmer who worked there... wrote an
>>>> allocation program for gasoline in the giant tanks at bulk
>>>> oil terminals. It was done in Turbo Pascal. She used sets
>>>> to keep up with days of the month for the allocation. For
>>>> instance, some allocation was every other day, so it was
>>>> (2,4,6,8,10,...,28,30). Some allocation was three times a
>>>> month on (10,20,30). Then she used the "in" operation with
>>>> the current day of the month (in a sequence of "if" statements),
>>>> to determine which allocations needed to be processed on
>>>> that day.
>>>>
>>>> Since the sets only needed a max of 31 items, it worked great.
>>> 31? Every other day needs more than 31 and leap year makes the
>>> other years' lists wrong.
>>>
>> I guess I was *not* clear, BAH. This was *monthly* allocation.
>> Things repeated every month, *not* yearly.
>
> So it was OK to have allocations done two days in a row if the
> spec was every other day? Oct. 1, Oct. 3, ..., Oct 31, Nov.1.
> Would that have been the schedule?
>
I think that the "every other day" allocation was done on
even numbered dates. That way, you always got at least *one*
day between allocations.
jmfb...@aol.com
Nope. You aren't looking at the problem as a time flow problem.
/BAH