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 2 of 2 — ← Prev page 1 [2]

#32407

On 8/22/2015 6:41 AM, Martin Gregorie wrote:
> 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.
>

I write code which compiles on both GCC and MSVC, and on PCs and 
Raspberry Pi, and also some code for microcontrollers as well (where, 
for example, Texas Instruments seems to supply their own C compiler for 
their MCUs, but if a person wants they can also use GCC).

it is better now at least than it once was...

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

#32441

On 8/21/2015 11:42 PM, BGB wrote:
> 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.

C99 compatible or almost C99 compilers are getting out there in most
environments from PC and upwards.

MSVC++, GCC, XLC, Solaris Studio, HP C etc..

Arne

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

#32444

On 8/30/2015 9:03 PM, Arne Vajhøj wrote:
> On 8/21/2015 11:42 PM, BGB wrote:
>> 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.
>
> C99 compatible or almost C99 compilers are getting out there in most
> environments from PC and upwards.
>
> MSVC++, GCC, XLC, Solaris Studio, HP C etc..
>

MSVC is sort of half-way C99. VS2013 got it a bit better at least...

but, anyways, pretty much anything "PC and upwards" will also have 
32-bit int...

where you are liable to see 16-bit 'int' at this point is mostly on 8/16 
bit microcontrollers, which are a bit hit and miss.

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

#32510

On 8/31/2015 2:09 AM, BGB wrote:
> On 8/30/2015 9:03 PM, Arne Vajhøj wrote:
>> On 8/21/2015 11:42 PM, BGB wrote:
>>> 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.
>>
>> C99 compatible or almost C99 compilers are getting out there in most
>> environments from PC and upwards.
>>
>> MSVC++, GCC, XLC, Solaris Studio, HP C etc..
>>
>
> MSVC is sort of half-way C99. VS2013 got it a bit better at least...

And VS2015 is almost fully compliant.

Arne

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

#32520

On 9/3/2015 7:46 PM, Arne Vajhøj wrote:
> On 8/31/2015 2:09 AM, BGB wrote:
>> On 8/30/2015 9:03 PM, Arne Vajhøj wrote:
>>> On 8/21/2015 11:42 PM, BGB wrote:
>>>> 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.
>>>
>>> C99 compatible or almost C99 compilers are getting out there in most
>>> environments from PC and upwards.
>>>
>>> MSVC++, GCC, XLC, Solaris Studio, HP C etc..
>>>
>>
>> MSVC is sort of half-way C99. VS2013 got it a bit better at least...
>
> And VS2015 is almost fully compliant.
>

yeah, could be.

still using 2013 here ATM for Win32 development. good enough for now.


dunno about Texas Instruments' compiler.

looking it up, apparently it defaults to C89 mode, but a C99 subset can 
be supported via compiler options.

apparently absent features (depends on target, for the chips I am using):
wide character support;
complex numbers;
floating point support (only supported on targets with an FPU);
various printf format specifiers;
...

apparently, the C++ compiler for the target also does an 'Embedded C++' 
variant.

though, on this target (MSP430G2xxx), the limited ROM space is a much 
bigger issue than the lack of some features. everything still needs to 
fit in a few kB of ROM (programs are fairly small and one-off, features 
added and removed with an eye to the remaining RAM and ROM space).


once long ago (~ 15-17 years ago), I messed some with compiling code for 
M68K, Z80, and 6502 in emulators. the compilers I was using at the time 
only did K&R.

not sure if many people are still seriously using Turbo C and DOS and/or 
Win16. I have encountered some embedded terminals and other things 
apparently still based on a shell over Windows 3.x, so it probably is 
still in use in some places.

I guess it is whatever is cheap and easy...


like, the chips I am using were mostly because they are reasonably 
affordable and DIP based (bulk price is around $0.50 each). DIP is 
useful for small-scale as it allows using sockets and wire-wrap (having 
PCBs made isn't free either).

one can get a lot more but it costs more...

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

#32402

On Fri, 21 Aug 2015 22:39:18 -0400, Arne Vajhøj wrote:

> On 8/21/2015 5:51 PM, BGB wrote:
>> 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.
>
The other issue has been the one of non-standard standard libraries that 
contained added compiler-specific or OS-specific functions while omitting 
many of the functions you'd expect to see. The examples that spring to 
mind were MicroWare's OS-9, Borland C and NCR UNIX (which used very non-
standard network interfacing). I've never used MS C compilers but have 
always wondered whether the Borland standard library was the way it was 
to match the MS libraries.

In practise, the nonstandard functions were pretty easy to fix by writing 
a compatibility library that, e.g. provided a version of Borlands strmfe()
function for use when porting code from the Borland compiler to one of 
the unices. You needed a library for each target, so I had/have three for 
moving code between Borland, OS-9 and Linux systems. On the bright side, 
these were small libraries and quite easy to write.
 
This issue should have been fixed by the POSIX standard, but is this the 
case?


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

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

#32405

On 22/08/2015 12:37, Martin Gregorie wrote:
> On Fri, 21 Aug 2015 22:39:18 -0400, Arne Vajhøj wrote:
>
>> On 8/21/2015 5:51 PM, BGB wrote:
>>> 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.
>>

<snip>

> In practise, the nonstandard functions were pretty easy to fix by writing
> a compatibility library that, e.g. provided a version of Borlands strmfe()
> function for use when porting code from the Borland compiler to one of
> the unices. You needed a library for each target, so I had/have three for
> moving code between Borland, OS-9 and Linux systems. On the bright side,
> these were small libraries and quite easy to write.
>
> This issue should have been fixed by the POSIX standard, but is this the
> case?

It's not just about non-standard functions and libraries though is it.
It's been a while but IIRC the GNU C compiler allowed/allows nested 
functions but the spec defined/defines no such thing.

Now that's a pretty fundamental 'feature' isn't it. It completely 
changes the architectural landscape.

No chance of a compliant compiler compiling that is there?

Never had any of these problems with Java :-)

Oh, don't forget to make your code portable.


-- 
Laughing Spam Fritter

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

#32411

On Sat, 22 Aug 2015 12:56:32 +0100, Eternal Hope wrote:

> It's not just about non-standard functions and libraries though is it.
> It's been a while but IIRC the GNU C compiler allowed/allows nested
> functions but the spec defined/defines no such thing.
>
Indeed, and I've never seen or attempted to use nested functions in C.
Maybe I don't delve into dark corners, but this is the first time I've 
ever heard nested function declarations mentioned in the same breath as C.
  
> Oh, don't forget to make your code portable.
>
Quite. And don't use C-spells or any other too-clever-by-half tricks that 
serve more to obfuscate than to make code run faster now we've got decent 
optimising compilers.


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

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

#32413

On 8/22/2015 1:04 PM, Martin Gregorie wrote:
> On Sat, 22 Aug 2015 12:56:32 +0100, Eternal Hope wrote:
>
>> It's not just about non-standard functions and libraries though is it.
>> It's been a while but IIRC the GNU C compiler allowed/allows nested
>> functions but the spec defined/defines no such thing.
>>
> Indeed, and I've never seen or attempted to use nested functions in C.
> Maybe I don't delve into dark corners, but this is the first time I've
> ever heard nested function declarations mentioned in the same breath as C.
>

most people don't use them, as they are compiler specific.

it is like using lambda blocks. they exist on some compilers, but are 
pretty much a novelty item best to be avoided.


>> Oh, don't forget to make your code portable.
>>
> Quite. And don't use C-spells or any other too-clever-by-half tricks that
> serve more to obfuscate than to make code run faster now we've got decent
> optimising compilers.
>

one mans' obfuscation is another mans' coding convention.

but, I guess it depends on what practices are in question.
I have seen the "obfuscation" argument used to try to attack things like 
people doing arithmetic using shift operators, but pretty much anyone 
who has been doing programming for a while is likely to be well-versed 
as to what the shift operators are and do (as well as the use of bitwise 
operators and hexadecimal).

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

#32442

On 8/22/2015 7:37 AM, Martin Gregorie wrote:
> On Fri, 21 Aug 2015 22:39:18 -0400, Arne Vajhøj wrote:
>> On 8/21/2015 5:51 PM, BGB wrote:
>>> 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.
>>
> The other issue has been the one of non-standard standard libraries that
> contained added compiler-specific or OS-specific functions while omitting
> many of the functions you'd expect to see. The examples that spring to
> mind were MicroWare's OS-9, Borland C and NCR UNIX (which used very non-
> standard network interfacing). I've never used MS C compilers but have
> always wondered whether the Borland standard library was the way it was
> to match the MS libraries.
>
> In practise, the nonstandard functions were pretty easy to fix by writing
> a compatibility library that, e.g. provided a version of Borlands strmfe()
> function for use when porting code from the Borland compiler to one of
> the unices. You needed a library for each target, so I had/have three for
> moving code between Borland, OS-9 and Linux systems. On the bright side,
> these were small libraries and quite easy to write.
>
> This issue should have been fixed by the POSIX standard, but is this the
> case?

If what you need is defined by POSIX and you are in a POSIX compliant
env then you are OK.

But there are a lot of things POSIX does not and non-*nix systems
are not always POSIX compliant.

Arne

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

#32401

On 21/08/2015 22:51, BGB wrote:
> 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.

Absolutely

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

I'd have to agree with this, in fact most of my commercial experience is 
enterprise focussed. I mainly do assembler and C for pleasure (among 
other things naturally :-)

> 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.

Horses for courses, completely agree.

I remember running a profiller on WebLogic running a not particularly 
heavyweight application that made use of the org.w3c.dom library 
implementation in a reference implementation of the language to 
manipulate xml and discovering that upwards of a MILLION String Objects 
were being held in memory at any one time.

Not exactly embedded territory is it :-)

-- 
Laughing Spam Fritter

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

#32414

On 8/22/2015 4:31 AM, Eternal Hope wrote:
> On 21/08/2015 22:51, BGB wrote:
>> 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:
>>>>
...
>>
>>> 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.
>
> Absolutely
>

yep.


>> like if one admits to knowing or ever using Java, then people
>> automatically assume that they are doing enterprise/business computing
>> stuff.
>
> I'd have to agree with this, in fact most of my commercial experience is
> enterprise focussed. I mainly do assembler and C for pleasure (among
> other things naturally :-)
>

yeah, and I have generally not gone anywhere near these, so I am a bit 
outside of the main Java demographic, but this may show in that I don't 
really use it all that often either (and usually then it has been 
incidental, like dealing with GWT or Android or J2ME).


>> 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.
>
> Horses for courses, completely agree.
>
> I remember running a profiller on WebLogic running a not particularly
> heavyweight application that made use of the org.w3c.dom library
> implementation in a reference implementation of the language to
> manipulate xml and discovering that upwards of a MILLION String Objects
> were being held in memory at any one time.
>
> Not exactly embedded territory is it :-)
>

yeah.


for another (incomplete) language intended more for use on embedded ARM 
targets, the logical string type was made to look like UTF-16, but was 
in-fact going to quietly use Windows-1252 for the underlying string 
representation in most cases, and the type would be quietly just a 
pointer to the first character of the string in the string table.

even as such, it is still too heavyweight to really be a good option for 
16-bit microcontrollers (C and ASM are pretty hard to beat here).


if one is looking at real-time embedded, some popular choices are C and 
C++, followed by Ada, Ladder Logic, and LabVIEW (these latter options 
being more common on things like PLCs and similar).


the language I was working on sort of resembled if C# used a syntax more 
resembling a Java/ActionScript3 hybrid, with modest tweaks, and use of 
RAII and explicit delete (more like C++).

unlike some of the other languages listed, the language was designed to 
more directly incorporate support for concurrent and asynchronous execution.

it was derived some from a parent language, but was getting a bit of 
tweaking and was being reimplemented mostly ground-up for the use-case 
(the predecessor was far too heavyweight to be viable even on fairly 
high-end embedded controllers, and in the redesigned VM).

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

#32398

On 8/21/2015 3: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'
> brigade.

Most OS are written in C.

To write an OS you need to get real close to the hardware and allow
a lot of funky stuff.

So ...

If one want a type safe, OO, everything well defined, WORA language
then pick something else than C.

Arne

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

#32404

On Fri, 21 Aug 2015 22:42:11 -0400, Arne Vajhøj wrote:

> To write an OS you need to get real close to the hardware and allow a
> lot of funky stuff.
>
Hardware emulation too. I started to write a 6809 emulator in Java, but 
moved the project to C when I discovered what a pain it was going to be 
to emulate the registers (8 or 16 bit unsigned arithmetic but with the 
option to treat the LHS bit as the sign) It was *much* easier to simply 
declare the registers as 'unsigned short'  or 'unsigned byte' than it was 
to fight with Java's insistence on signed arithmetic.
 

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

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

#32406

On 22/08/2015 12:53, Martin Gregorie wrote:
> On Fri, 21 Aug 2015 22:42:11 -0400, Arne Vajhøj wrote:
>
>> To write an OS you need to get real close to the hardware and allow a
>> lot of funky stuff.
>>
> Hardware emulation too. I started to write a 6809 emulator in Java, but
> moved the project to C when I discovered what a pain it was going to be
> to emulate the registers (8 or 16 bit unsigned arithmetic but with the
> option to treat the LHS bit as the sign) It was *much* easier to simply
> declare the registers as 'unsigned short'  or 'unsigned byte' than it was
> to fight with Java's insistence on signed arithmetic.


https://docs.oracle.com/javase/8/docs/api/java/lang/Integer.html

unsigned ops agogo

-- 
Laughing Spam Fritter

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

#32410

On Sat, 22 Aug 2015 13:11:41 +0100, Eternal Hope wrote:

> On 22/08/2015 12:53, Martin Gregorie wrote:
>> On Fri, 21 Aug 2015 22:42:11 -0400, Arne Vajhøj wrote:
>>
>>> To write an OS you need to get real close to the hardware and allow a
>>> lot of funky stuff.
>>>
>> Hardware emulation too. I started to write a 6809 emulator in Java, but
>> moved the project to C when I discovered what a pain it was going to be
>> to emulate the registers (8 or 16 bit unsigned arithmetic but with the
>> option to treat the LHS bit as the sign) It was *much* easier to simply
>> declare the registers as 'unsigned short'  or 'unsigned byte' than it
>> was to fight with Java's insistence on signed arithmetic.
> 
> 
> https://docs.oracle.com/javase/8/docs/api/java/lang/Integer.html
> 
> unsigned ops agogo

Integer is a bit too long for what I need: all the 6809 registers are 8 
or 16 bits. Byte and Short are the obvious Java classes to use but, then 
again, Integer,Byte and Short all only do a subset of unsigned 
arithmetic. Since none of them do unsigned addition or subtraction and 
none of them have any facilities for treating the MSB as a sign or 
reporting overflow - all of which are needed to emulate the registers, it 
remains much easier to do it in C.

This is just an observation that Java is unsuitable for some 
applications, not a criticism.

Yeah, I know I could use native code for this sort of stuff but, as much 
of the reason for using Java was to make the emulator fully portable, 
dropping bits of native C into the mix would probably have impacted that 
aim.  
    
Meanwhile C fits the bill very nicely.


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

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

#32412

On 22/08/2015 18:55, Martin Gregorie wrote:
> On Sat, 22 Aug 2015 13:11:41 +0100, Eternal Hope wrote:
>
>> On 22/08/2015 12:53, Martin Gregorie wrote:
>>> On Fri, 21 Aug 2015 22:42:11 -0400, Arne Vajhøj wrote:
>>>
>>>> To write an OS you need to get real close to the hardware and allow a
>>>> lot of funky stuff.
>>>>
>>> Hardware emulation too. I started to write a 6809 emulator in Java, but
>>> moved the project to C when I discovered what a pain it was going to be
>>> to emulate the registers (8 or 16 bit unsigned arithmetic but with the
>>> option to treat the LHS bit as the sign) It was *much* easier to simply
>>> declare the registers as 'unsigned short'  or 'unsigned byte' than it
>>> was to fight with Java's insistence on signed arithmetic.
>>
>>
>> https://docs.oracle.com/javase/8/docs/api/java/lang/Integer.html
>>
>> unsigned ops agogo
>
> Integer is a bit too long for what I need: all the 6809 registers are 8
> or 16 bits. Byte and Short are the obvious Java classes to use but, then
> again, Integer,Byte and Short all only do a subset of unsigned
> arithmetic. Since none of them do unsigned addition or subtraction and
> none of them have any facilities for treating the MSB as a sign or
> reporting overflow - all of which are needed to emulate the registers, it
> remains much easier to do it in C.
>
> This is just an observation that Java is unsuitable for some
> applications, not a criticism.

Heh heh, no problem here, criticise away, just put your tin hat on and 
avoid the shrapnel, although I don't think anyone would say that Java is 
perfect ... I mean *how many* classes in the latest distro. I preferred 
it when you had to include jars to get extended functionality. Made it 
more geeky some how :-)

Also Java doesn't seem to inspire people to starry eyed zealotry in the 
same way that C seems to.

> Yeah, I know I could use native code for this sort of stuff but, as much
> of the reason for using Java was to make the emulator fully portable,
> dropping bits of native C into the mix would probably have impacted that
> aim.
>
> Meanwhile C fits the bill very nicely.
>
>


-- 
Laughing Spam Fritter

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

#32431

On Sat, 22 Aug 2015 11:53:01 +0000 (UTC), Martin Gregorie
<martin@address-in-sig.invalid> wrote:

>On Fri, 21 Aug 2015 22:42:11 -0400, Arne Vajhøj wrote:
>
>> To write an OS you need to get real close to the hardware and allow a
>> lot of funky stuff.
>>
>Hardware emulation too. I started to write a 6809 emulator in Java, but 
>moved the project to C when I discovered what a pain it was going to be 
>to emulate the registers (8 or 16 bit unsigned arithmetic but with the 
>option to treat the LHS bit as the sign) It was *much* easier to simply 
>declare the registers as 'unsigned short'  or 'unsigned byte' than it was 
>to fight with Java's insistence on signed arithmetic.

     I remember hassling in Java for a few hours with building 32-bit
IP addresses from four octets because of Java's insistence on signed.
In C, with its unsigned, it would have been a minute or so.

Sincerely,

Gene Wirchenko

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

#32443

On 8/26/2015 12:44 PM, Gene Wirchenko wrote:
> On Sat, 22 Aug 2015 11:53:01 +0000 (UTC), Martin Gregorie
> <martin@address-in-sig.invalid> wrote:
>> On Fri, 21 Aug 2015 22:42:11 -0400, Arne Vajhøj wrote:
>>> To write an OS you need to get real close to the hardware and allow a
>>> lot of funky stuff.
>>>
>> Hardware emulation too. I started to write a 6809 emulator in Java, but
>> moved the project to C when I discovered what a pain it was going to be
>> to emulate the registers (8 or 16 bit unsigned arithmetic but with the
>> option to treat the LHS bit as the sign) It was *much* easier to simply
>> declare the registers as 'unsigned short'  or 'unsigned byte' than it was
>> to fight with Java's insistence on signed arithmetic.
>
>       I remember hassling in Java for a few hours with building 32-bit
> IP addresses from four octets because of Java's insistence on signed.
> In C, with its unsigned, it would have been a minute or so.

ubyte/ushort/uint/ulong sure would be nice.

If they had made byte unsigned and added sbyte 20 years ago then it
would have been even better, but too late now.

Arne

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

#32378

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?

There are multiple Java compilers:

javac
ecj
gcj
jikes

I have never really looked into what they were written in, because
that is irrelevant for java development.

But my guess would be:

javac - Java with compiler driver in C++
ecj - Java
gcj - C/C++
jikes - C/C++

Arne

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web