Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #32370 > unrolled thread

is the java compiler written in c

Back to article view | Back to comp.lang.java.programmer

Contents

  is the java compiler written in c gdotone@gmail.com - 2015-08-19 12:41 -0700
    Re: is the java compiler written in c Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-08-19 16:06 -0400
      Re: is the java compiler written in c gdotone@gmail.com - 2015-08-19 16:12 -0700
        Re: is the java compiler written in c Martin Gregorie <martin@address-in-sig.invalid> - 2015-08-20 11:08 +0000
          Re: is the java compiler written in c Arne Vajhøj <arne@vajhoej.dk> - 2015-08-20 20:34 -0400
        Re: is the java compiler written in c Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-08-20 07:44 -0400
        Re: is the java compiler written in c e.d.programmer@gmail.com - 2015-08-20 06:36 -0700
          Re: is the java compiler written in c gdotone@gmail.com - 2015-08-20 18:58 -0700
            Re: is the java compiler written in c Arne Vajhøj <arne@vajhoej.dk> - 2015-08-20 22:13 -0400
              Re: is the java compiler written in c g g <gdotone@gmail.com> - 2015-08-20 19:57 -0700
                Re: is the java compiler written in c Arne Vajhøj <arne@vajhoej.dk> - 2015-08-21 21:25 -0400
        Re: is the java compiler written in c Eternal Hope <laughingspam99@gmail.com> - 2015-08-21 08:15 +0100
          Re: is the java compiler written in c e.d.programmer@gmail.com - 2015-08-21 06:56 -0700
            Re: is the java compiler written in c Eternal Hope <laughingspam99@gmail.com> - 2015-08-21 15:32 +0100
          Re: is the java compiler written in c BGB <cr88192@hotmail.com> - 2015-08-21 16:51 -0500
            Re: is the java compiler written in c Martin Gregorie <martin@address-in-sig.invalid> - 2015-08-21 23:32 +0000
              Re: is the java compiler written in c BGB <cr88192@hotmail.com> - 2015-08-21 23:35 -0500
            Re: is the java compiler written in c Arne Vajhøj <arne@vajhoej.dk> - 2015-08-21 22:39 -0400
              Re: is the java compiler written in c BGB <cr88192@hotmail.com> - 2015-08-21 22:42 -0500
                Re: is the java compiler written in c Martin Gregorie <martin@address-in-sig.invalid> - 2015-08-22 11:41 +0000
                  Re: is the java compiler written in c BGB <cr88192@hotmail.com> - 2015-08-22 10:03 -0500
                Re: is the java compiler written in c Arne Vajhøj <arne@vajhoej.dk> - 2015-08-30 22:03 -0400
                  Re: is the java compiler written in c BGB <cr88192@hotmail.com> - 2015-08-31 01:09 -0500
                    Re: is the java compiler written in c Arne Vajhøj <arne@vajhoej.dk> - 2015-09-03 20:46 -0400
                      Re: is the java compiler written in c BGB <cr88192@hotmail.com> - 2015-09-04 10:01 -0500
              Re: is the java compiler written in c Martin Gregorie <martin@address-in-sig.invalid> - 2015-08-22 11:37 +0000
                Re: is the java compiler written in c Eternal Hope <laughingspam99@gmail.com> - 2015-08-22 12:56 +0100
                  Re: is the java compiler written in c Martin Gregorie <martin@address-in-sig.invalid> - 2015-08-22 18:04 +0000
                    Re: is the java compiler written in c BGB <cr88192@hotmail.com> - 2015-08-22 14:27 -0500
                Re: is the java compiler written in c Arne Vajhøj <arne@vajhoej.dk> - 2015-08-30 22:06 -0400
            Re: is the java compiler written in c Eternal Hope <laughingspam99@gmail.com> - 2015-08-22 10:31 +0100
              Re: is the java compiler written in c BGB <cr88192@hotmail.com> - 2015-08-23 01:31 -0500
          Re: is the java compiler written in c Arne Vajhøj <arne@vajhoej.dk> - 2015-08-21 22:42 -0400
            Re: is the java compiler written in c Martin Gregorie <martin@address-in-sig.invalid> - 2015-08-22 11:53 +0000
              Re: is the java compiler written in c Eternal Hope <laughingspam99@gmail.com> - 2015-08-22 13:11 +0100
                Re: is the java compiler written in c Martin Gregorie <martin@address-in-sig.invalid> - 2015-08-22 17:55 +0000
                  Re: is the java compiler written in c Eternal Hope <laughingspam99@gmail.com> - 2015-08-22 19:59 +0100
              Re: is the java compiler written in c Gene Wirchenko <genew@telus.net> - 2015-08-26 09:44 -0700
                Re: is the java compiler written in c Arne Vajhøj <arne@vajhoej.dk> - 2015-08-30 22:11 -0400
    Re: is the java compiler written in c Arne Vajhøj <arne@vajhoej.dk> - 2015-08-19 19:35 -0400

Page 1 of 2  [1] 2  Next page →

#32370 — is the java compiler written in c

is the java compiler written in c?

or is written in java and assembler?

[toc] | [next] | [standalone]

#32371

On 8/19/2015 3:41 PM, gdotone@gmail.com wrote:
> is the java compiler written in c?
>
> or is written in java and assembler?

     Hmmm...  The best answer might be "Yes."

     On most (maybe all) platforms, javac is a small native executable
written in ... well, written in whatever is (or are) convenient for
writing small native executables.

     The job of javac is to launch a Java Virtual Machine, which is
another, much larger and more intricate native executable.  Again,
the JVM is written in platform-specific languages; I believe C++ was
used for most of Sun's early JVM's and may still be prevalent.

     The other job of javac is to tell the JVM what class to load and
run, and that class and the other classes it employs are either provided
directly by the JVM (like Object and Class) or are written in Java.
This suite of classes make up a Java program that parses Java source
code, turns it into JVM byte code, and writes class files.

     ... and, of course, a Java class can have native methods.  Many of
Java's standard classes do (hard to perform I/O without a few system
calls, you know), and it's possible that some of the compiler-specific
classes do, too.  It seems unlikely that the compiler classes would need
their own native methods, but I have no actual information to the
contrary.

     So: The Java compiler is written in Java plus whatever languages
implement the JVM plus whatever languages implement native methods
plus whatever languages implement the little javac launcher.

     Finally, I have a counter-question: Why do you care?

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#32374

On Wednesday, August 19, 2015 at 4:06:41 PM UTC-4, Eric Sosman wrote:
 
>      Finally, I have a counter-question: Why do you care?

c has many unspecified and undefines, all for the flexibility of the language, so that it can be used to solve many different problems.

not that i'm well versed in c, but with so many security holes in almost everything, maybe c should become much tighter or maybe a different lang. should be tried for all these things to be built on. 

yes, speed, time to market, etc., but ... man a new exploit every week if not two or three...

i guess nothing would be perfect... just thinking out loud, so to write.

Thanks Eric for the explanation.

[toc] | [prev] | [next] | [standalone]

#32380

On Wed, 19 Aug 2015 16:12:25 -0700, gdotone wrote:

> not that i'm well versed in c, but with so many security holes in almost
> everything, maybe c should become much tighter or maybe a different
> lang. should be tried for all these things to be built on.
>
A quick and easy fix for a lot of C gotchas is to scan the source for 
calls of the str... functions and replace them with their strn... 
equivalents.

C as it stands to too useful and too widespread to change, the more so 
because a lot of compilers work by translating the source language into C 
and then compiling that. This is quite a good idea since the translator 
can add all the security traps, optimisations, etc. you might want and 
you end up with a language implementation that's just as portable as the 
underlying C compiler.

Examples: traditional C++ is just ANSI C with the cfront preprocessor 
replacing the ANSI C preprocessor, cpre. The GNU implementations of 
fortran77 and COBOL use the same approach. And, of course, lex&yacc, 
flex&bison and Coco/R, which are all compiler generators, work by 
translating their source files into C and then compiling that.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#32384

On 8/20/2015 7:08 AM, Martin Gregorie wrote:
> On Wed, 19 Aug 2015 16:12:25 -0700, gdotone wrote:
>> not that i'm well versed in c, but with so many security holes in almost
>> everything, maybe c should become much tighter or maybe a different
>> lang. should be tried for all these things to be built on.
>>
> A quick and easy fix for a lot of C gotchas is to scan the source for
> calls of the str... functions and replace them with their strn...
> equivalents.
>
> C as it stands to too useful and too widespread to change, the more so
> because a lot of compilers work by translating the source language into C
> and then compiling that. This is quite a good idea since the translator
> can add all the security traps, optimisations, etc. you might want and
> you end up with a language implementation that's just as portable as the
> underlying C compiler.
>
> Examples: traditional C++ is just ANSI C with the cfront preprocessor
> replacing the ANSI C preprocessor, cpre.

If you by traditional C++ means C++ before 1990 then yes.

>                                         The GNU implementations of
> fortran77 and COBOL use the same approach.

I am pretty sure that g77 only calls f771 that generate assembler
code and and not use cc1 at all.

Arne

[toc] | [prev] | [next] | [standalone]

#32381

On 8/19/2015 7:12 PM, gdotone@gmail.com wrote:
> On Wednesday, August 19, 2015 at 4:06:41 PM UTC-4, Eric Sosman wrote:
>
>>       Finally, I have a counter-question: Why do you care?
>
> c has many unspecified and undefines, all for the flexibility of the language, so that it can be used to solve many different problems.

     Part of the job of a C programmer is to understand the portability
implications of different parts of the language.  (This is part of a
Java programmer's job, too, although to a lesser extent than for C.)
A well-informed and careful programmer can write C code that avoids the
gotchas -- or even that takes advantage of them.

     Besides, it's my understanding that most of the JVM is written in
C++, not in C.  Anyone who thinks C++ and C are approximately the same
knows neither of them.

> not that i'm well versed in c, but with so many security holes in almost everything, maybe c should become much tighter or maybe a different lang. should be tried for all these things to be built on.

     Are you assuming that Java's much-publicized security gaffes are
due to an underlying C++ implementation?  Do you have any evidence to
support such an assumption?

     The truth of the matter is that Java's problems are due to its
reliance on silicon, a plentiful element that hackers can easily
acquire.  (Discuss.)

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#32382

On Wednesday, August 19, 2015 at 7:12:41 PM UTC-4, gdo...@gmail.com wrote:
> not that i'm well versed in c, but with so many security holes in almost everything, maybe c should become much tighter or maybe a different lang. should be tried for all these things to be built on. 
> 
> yes, speed, time to market, etc., but ... man a new exploit every week if not two or three...
> 
> i guess nothing would be perfect... just thinking out loud, so to write.
> 
> Thanks Eric for the explanation.

How do you propose to 'make things tighter'?  If you can write software that is impossible to exploit and still simple and reliable enough for end users to adopt, do it, you'll get rich.  I assume everything that is accessible is exploitable.

[toc] | [prev] | [next] | [standalone]

#32385

On Thursday, August 20, 2015 at 9:36:37 AM UTC-4, e.d.pro...@gmail.com wrote:

> How do you propose to 'make things tighter'?  If you can write software that is impossible to exploit and still simple and reliable enough for end users to adopt, do it, you'll get rich.  I assume everything that is accessible is exploitable.

just as an idea to start it off, for the more brilliant among us, those guys and ladies that write compilers, which i freely admit not to be one, no undefined and no unspecified behaviors in the language. so i guess that would mean the behaviors are defined or not allowed. my understanding is java goes down that path better than C, but my understanding could be wrong.

[toc] | [prev] | [next] | [standalone]

#32386

On 8/20/2015 9:58 PM, gdotone@gmail.com wrote:
> On Thursday, August 20, 2015 at 9:36:37 AM UTC-4,
> e.d.pro...@gmail.com wrote:
>> How do you propose to 'make things tighter'?  If you can write
>> software that is impossible to exploit and still simple and
>> reliable enough for end users to adopt, do it, you'll get rich.  I
>> assume everything that is accessible is exploitable.
>
> just as an idea to start it off, for the more brilliant among us,
> those guys and ladies that write compilers, which i freely admit not
> to be one, no undefined and no unspecified behaviors in the language.
> so i guess that would mean the behaviors are defined or not allowed.
> my understanding is java goes down that path better than C, but my
> understanding could be wrong.

Java has way less undefined and implementation specific behavior
than C.

But how does that relate to the language of the Java compiler?

Arne

[toc] | [prev] | [next] | [standalone]

#32387

On Thursday, August 20, 2015 at 10:13:54 PM UTC-4, Arne Vajhøj wrote:
> On 8/20/2015 9:58 PM, gdotone@gmail.com wrote:
> > On Thursday, August 20, 2015 at 9:36:37 AM UTC-4,
> > e.d.pro...@gmail.com wrote:
> >> How do you propose to 'make things tighter'?  If you can write
> >> software that is impossible to exploit and still simple and
> >> reliable enough for end users to adopt, do it, you'll get rich.  I
> >> assume everything that is accessible is exploitable.

> Java has way less undefined and implementation specific behavior
> than C.
> 
> But how does that relate to the language of the Java compiler?
> 
> Arne

Arne, I was writing to e.d.pro... question in that response.

 

[toc] | [prev] | [next] | [standalone]

#32396

On 8/20/2015 10:57 PM, g g wrote:
> On Thursday, August 20, 2015 at 10:13:54 PM UTC-4, Arne Vajhøj wrote:
>> On 8/20/2015 9:58 PM, gdotone@gmail.com wrote:
>>> On Thursday, August 20, 2015 at 9:36:37 AM UTC-4,
>>> e.d.pro...@gmail.com wrote:
>>>> How do you propose to 'make things tighter'?  If you can write
>>>> software that is impossible to exploit and still simple and
>>>> reliable enough for end users to adopt, do it, you'll get rich.  I
>>>> assume everything that is accessible is exploitable.
>
>> Java has way less undefined and implementation specific behavior
>> than C.
>>
>> But how does that relate to the language of the Java compiler?
>
> Arne, I was writing to e.d.pro... question in that response.

Ah. Mea culpa.

Arne

[toc] | [prev] | [next] | [standalone]

#32388

On 20/08/2015 00:12, gdotone@gmail.com wrote:
> On Wednesday, August 19, 2015 at 4:06:41 PM UTC-4, Eric Sosman wrote:
>
>>       Finally, I have a counter-question: Why do you care?
>
> c has many unspecified and undefines, all for the flexibility of the language, so that it can be used to solve many different problems.

comp.lang.c is a fascinating read.

start:

On the one hand, any suggestion that the official C specification is 
'tightened up' so that the almost endless 'undefined behaviors' are more 
rigidly defined is met with howls of protest because of the

'C is so powerful because you can do anything you want with it and 
that's the way we like it'

brigade.

On the other hand there is endless droning on about making everything 
you do as 'portable' as possible which requires an in depth 
understanding of undefined behavior, despite the fact that the 
definition of undefined actually equates to 'is unknowable in a 
particular implementation' etc etc'.

If one has the temerity to post c code that does something that is 
platform specific, or, even worse implementation specific as I have done 
in the past you are instantly jumped on and reprimanded for a poor 
understanding of a specification that by its very nature can never be 
fully understood due to the almost endless undefined things.

If you then suggest that it might be time to make certain undefined 
behavious better defined then  ...

goto start

You might consider this situation a dichotomy where set membership is 
mutually exclusive. Not so, Some seem to have a foot firmly rooted in 
both camps possibly due to some rule that determines set membership 
imported from in a parallel universe.

Like I say, it's  fascinating read.


-- 
Laughing Spam Fritter

[toc] | [prev] | [next] | [standalone]

#32391

On Friday, August 21, 2015 at 3:15:14 AM UTC-4, Eternal Hope wrote:
> On the other hand there is endless droning on about making everything 
> you do as 'portable' as possible which requires an in depth 
> understanding of undefined behavior, despite the fact that the 
> definition of undefined actually equates to 'is unknowable in a 
> particular implementation' etc etc'.
> 
> If one has the temerity to post c code that does something that is 
> platform specific, or, even worse implementation specific as I have done 
> in the past you are instantly jumped on and reprimanded for a poor 
> understanding of a specification that by its very nature can never be 
> fully understood due to the almost endless undefined things.

"Known unknowns result from phenomena which are recognized, but poorly understood. On the other hand, unknown unknowns are phenomena which cannot be expected because there has been no prior experience or theoretical basis for expecting the phenomena."
https://en.wikipedia.org/wiki/There_are_known_knowns

[toc] | [prev] | [next] | [standalone]

#32392

On 21/08/2015 14:56, e.d.programmer@gmail.com wrote:
> On Friday, August 21, 2015 at 3:15:14 AM UTC-4, Eternal Hope wrote:
>> On the other hand there is endless droning on about making everything
>> you do as 'portable' as possible which requires an in depth
>> understanding of undefined behavior, despite the fact that the
>> definition of undefined actually equates to 'is unknowable in a
>> particular implementation' etc etc'.
>>
>> If one has the temerity to post c code that does something that is
>> platform specific, or, even worse implementation specific as I have done
>> in the past you are instantly jumped on and reprimanded for a poor
>> understanding of a specification that by its very nature can never be
>> fully understood due to the almost endless undefined things.
>
> "Known unknowns result from phenomena which are recognized, but poorly understood. On the other hand, unknown unknowns are phenomena which cannot be expected because there has been no prior experience or theoretical basis for expecting the phenomena."
> https://en.wikipedia.org/wiki/There_are_known_knowns

Well quite !

Furthermore, if something is undefined by the specification then even if 
the actual (but undefined) behaviour is observed for a particular 
implementation (of the specifiation) and appears to be consistent 
betweeen invocations the very fact that it is undefined implies that you 
still cannot be confident that the undefined but observably consistent 
behavior will be consistent for the (infinite?) set of possible program 
states because it's undefined.

If you want to do stuff that lets you muggins about with the guts of the 
machine use c (and gdb) and be thankful to K and R

If you want to write portable code use Java

I have a sneaking suspicion that actually, c zealots are quite jealous 
of Java's ability to translocate with little trouble and try desperately 
to convince themselves that their favorite dialect is perfectly capable 
of producing portable code as long as you know the unknowable and 
studiously avoid using it ... the unknowable that is although how you 
know it when it's unknowable ... etc etc



-- 
Laughing Spam Fritter

[toc] | [prev] | [next] | [standalone]

#32394

On 8/21/2015 2:15 AM, Eternal Hope wrote:
> On 20/08/2015 00:12, gdotone@gmail.com wrote:
>> On Wednesday, August 19, 2015 at 4:06:41 PM UTC-4, Eric Sosman wrote:
>>
>>>       Finally, I have a counter-question: Why do you care?
>>
>> c has many unspecified and undefines, all for the flexibility of the
>> language, so that it can be used to solve many different problems.
>
> comp.lang.c is a fascinating read.
>
> start:
>
> On the one hand, any suggestion that the official C specification is
> 'tightened up' so that the almost endless 'undefined behaviors' are more
> rigidly defined is met with howls of protest because of the
>
> 'C is so powerful because you can do anything you want with it and
> that's the way we like it'
>
> brigade.
>

you can tighten it up in a way which works on most targets, say, making 
'int' always be 32 bits, ...

but, this hinders use on some targets (MSP430 or AVR8) which work 
primarily on 8 and 16 bit units.

granted, you probably wont use the same code on an MSP430 as you would 
on a PC, but code *could* be moved between, say, an MSP430 and a 
Cortex-M or similar.

the MSP or AVR are enough unlike a PC though, to where one is generally 
better off emulating the chip (and any attached peripheral hardware), 
rather than try to rig things up to fake it on a PC via wrappers (this 
is a more common strategy for code targeting ARM based controllers).


> On the other hand there is endless droning on about making everything
> you do as 'portable' as possible which requires an in depth
> understanding of undefined behavior, despite the fact that the
> definition of undefined actually equates to 'is unknowable in a
> particular implementation' etc etc'.
>

or, narrowing it down to a range of platforms for which it will work, 
say, 32 and 64 bit Windows and Linux.


> If one has the temerity to post c code that does something that is
> platform specific, or, even worse implementation specific as I have done
> in the past you are instantly jumped on and reprimanded for a poor
> understanding of a specification that by its very nature can never be
> fully understood due to the almost endless undefined things.
>

more of a c.l.c thing, not so much C in general.
most real-world code needs a pile of #ifdef's and platform specific 
sequences for anything in may run on.


> If you then suggest that it might be time to make certain undefined
> behavious better defined then  ...
>
> goto start
>
> You might consider this situation a dichotomy where set membership is
> mutually exclusive. Not so, Some seem to have a foot firmly rooted in
> both camps possibly due to some rule that determines set membership
> imported from in a parallel universe.
>
> Like I say, it's  fascinating read.
>

every language has tradeoffs.

like if one admits to knowing or ever using Java, then people 
automatically assume that they are doing enterprise/business computing 
stuff.

but, in the past, I was mostly doing games stuff, as well as a lot of 
compiler/VM stuff;
now more recently, it has moved more into a mix of embedded programming. 
generally real-time motor-controls type stuff. and some stuff on 
hardware with amazingly bad hardware stats (several MHz and a few kB of 
ROM, and *bytes* of RAM).

one could be like, "how does one do anything with only a few kB of 
ROM?", but it partly is a matter of perspective. if you expect to use a 
big complex program, it wont work. if can do everything in maybe a few 
hundred lines of C (sans comments), then, say, a 2kB ROM space and 256B 
of RAM is sufficient.

[toc] | [prev] | [next] | [standalone]

#32395

On Fri, 21 Aug 2015 16:51:00 -0500, BGB wrote:

> one could be like, "how does one do anything with only a few kB of
> ROM?", but it partly is a matter of perspective. if you expect to use a
> big complex program, it wont work. if can do everything in maybe a few
> hundred lines of C (sans comments), then, say, a 2kB ROM space and 256B
> of RAM is sufficient.
>
Slightly OT I know, but it can be an interesting experience to get 
something running on a Parallax BS2  - its programmed in P-coded integer 
BASIC with room doe maybe 200 lines of code and has 32 bytes of RAM, 
which includes the memory-mapped I/o ports However, at least to can store 
constants in the flash memory that holds the user code. If you think it 
out appropriately you can do more than you can expect, not least because 
variables can be 1,2 or 8 bits in length.

I've not (yet) used one, but I'd imagine that using a PICAXE chip would 
be quite similar.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#32400

On 8/21/2015 6:32 PM, Martin Gregorie wrote:
> On Fri, 21 Aug 2015 16:51:00 -0500, BGB wrote:
>
>> one could be like, "how does one do anything with only a few kB of
>> ROM?", but it partly is a matter of perspective. if you expect to use a
>> big complex program, it wont work. if can do everything in maybe a few
>> hundred lines of C (sans comments), then, say, a 2kB ROM space and 256B
>> of RAM is sufficient.
>>
> Slightly OT I know, but it can be an interesting experience to get
> something running on a Parallax BS2  - its programmed in P-coded integer
> BASIC with room doe maybe 200 lines of code and has 32 bytes of RAM,
> which includes the memory-mapped I/o ports However, at least to can store
> constants in the flash memory that holds the user code. If you think it
> out appropriately you can do more than you can expect, not least because
> variables can be 1,2 or 8 bits in length.
>
> I've not (yet) used one, but I'd imagine that using a PICAXE chip would
> be quite similar.
>

yeah, I have mostly recently been messing with MSP430G2232 chips (2kB 
ROM, 256kB RAM, 8ch ADC).

despite their seemingly trivial sized ROM, I have used one essentially 
for a simplistic 3-phase VFD. it has both 2 and 3 phase outputs, 
selectable mode/direction (currently 8 modes and forward/reverse, modes 
select between 2 and 3 phase and wave-function), and logic for doing 
voltage regulation (*).

though, ironically, in a VFD like this, the transistors work out to a 
lot more expense than the controllers (you can use expensive MOSFETs or 
cheaper BJTs, but one is looking at bulk prices of around $0.60 for the 
MCU, and about $1 for each MOSFET).


*: DC->DC conversion being used to create a specific voltage for the 
output rail (may vary based on drive frequency). at present, this would 
be for doing 12V -> 55V which is needed for approx 24 VAC output, where 
a little over 2x the target voltage is needed for 3-phase.

3-phase requires a rail-voltage of roughly the peak-to-peak voltage, 
which would work out to 68v for a sine-wave. however, if the wave 
function is tweaked some (say, so RMS is closer to 0.9 P-P vs 0.71 P-P), 
then a 55V rail is sufficient (and this is in-turn due to otherwise 
needing more expensive transistors).

though, doing a VFD with a UI and/or a control protocol would likely 
still require a bigger MCU.

[toc] | [prev] | [next] | [standalone]

#32397

On 8/21/2015 5:51 PM, BGB wrote:
> On 8/21/2015 2:15 AM, Eternal Hope wrote:
>>
>> On the one hand, any suggestion that the official C specification is
>> 'tightened up' so that the almost endless 'undefined behaviors' are more
>> rigidly defined is met with howls of protest because of the
>>
>> 'C is so powerful because you can do anything you want with it and
>> that's the way we like it'
>
> you can tighten it up in a way which works on most targets, say, making
> 'int' always be 32 bits, ...

With C99 that should really not be necessary.

>> On the other hand there is endless droning on about making everything
>> you do as 'portable' as possible which requires an in depth
>> understanding of undefined behavior, despite the fact that the
>> definition of undefined actually equates to 'is unknowable in a
>> particular implementation' etc etc'.
>>
>
> or, narrowing it down to a range of platforms for which it will work,
> say, 32 and 64 bit Windows and Linux.

But that would be a complete no go for C given how many other platforms
relies on C.

Arne

[toc] | [prev] | [next] | [standalone]

#32399

On 8/21/2015 9:39 PM, Arne Vajhøj wrote:
> On 8/21/2015 5:51 PM, BGB wrote:
>> On 8/21/2015 2:15 AM, Eternal Hope wrote:
>>>
>>> On the one hand, any suggestion that the official C specification is
>>> 'tightened up' so that the almost endless 'undefined behaviors' are more
>>> rigidly defined is met with howls of protest because of the
>>>
>>> 'C is so powerful because you can do anything you want with it and
>>> that's the way we like it'
>>
>> you can tighten it up in a way which works on most targets, say, making
>> 'int' always be 32 bits, ...
>
> With C99 that should really not be necessary.
>

possible, but this in-turn assumes you are using a compiler which 
supports C99.

C99 support is a little less widespread than targets which use a 32-bit int.


>>> On the other hand there is endless droning on about making everything
>>> you do as 'portable' as possible which requires an in depth
>>> understanding of undefined behavior, despite the fact that the
>>> definition of undefined actually equates to 'is unknowable in a
>>> particular implementation' etc etc'.
>>>
>>
>> or, narrowing it down to a range of platforms for which it will work,
>> say, 32 and 64 bit Windows and Linux.
>
> But that would be a complete no go for C given how many other platforms
> relies on C.
>

not narrowing C proper, rather, assuming "portable" to mean "portable to 
platforms with approximately these parameters".

while not universally true, most things are not absolutes, and one can 
limit things to the range of targets they care about, or which probably 
have the resources to run the code in question.

there are odd targets, but one can mostly ignore them and get along 
pretty good.


this doesn't mean one can't also write code for 8/16 bit 
microcontrollers, but these are different enough that one probably isn't 
going to be using the same code both on their MCU and on their PC.

[toc] | [prev] | [next] | [standalone]

#32403

On Fri, 21 Aug 2015 22:42:43 -0500, BGB wrote:

> there are odd targets, but one can mostly ignore them and get along
> pretty good.
>
It helps a lot if you're using the GNU compiler. I was pleased, though 
not totally surprised, to see how easy it is to port C code from my Linux 
PAE system to my RaspberryPi. 


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web