Re: "Death To C"

From	BGB <cr88192@hotmail.com>
Newsgroups	comp.lang.c
Subject	Re: "Death To C"
Date	2015-05-08 09:09 -0500
Organization	albasani.net
Message-ID	<miig9e$a4d$1@news.albasani.net> (permalink)
References	<mi8hvq$p37$1@dont-email.me> <1d3d39e1-3907-4222-9369-154784461fbd@googlegroups.com> <mi8nfs$fll$1@dont-email.me>

Show all headers | View raw

On 5/4/2015 4:15 PM, Bartc wrote:
> On 04/05/2015 21:22, Malcolm McLean wrote:
>> On Monday, May 4, 2015 at 8:41:55 PM UTC+1, Lynn McGuire wrote:
>>> "Death To C"
>>>      http://techcrunch.com/2015/05/02/and-c-plus-plus-too/
>
>> Thousands of language are proposed (I've done it myself, Minibasic
>> has found a niche as a simple, customisable Basic variant). Only
>> a handful are ever used for anything more than a demo project by
>> the language implementer and a few tools for the same language.
>
> I've created many (although all very similar), mostly to help me do my
> work over a period of nearly 20 years. For various reasons, they just
> helped me be very productive, even allowing for a couple of months to
> put one together. Some were built-in to applications and were used by
> other people.
>
> But now it's just for fun. However they aren't 'toy' implementations and
> can do real work. They just lack extensive libraries so I make it a
> priority to allow external libraries to be used. Ones with an interface
> defined in C are the simplest.
>

yeah. my stuff is also a bit immature in many areas, but is more special 
purpose.

I have two major languages I am using in VMs at present:
BGBScript, which is loosely a mix of JavaScript and ActionScript, Java, 
C#, and C. syntactically, it is closer to an AS3/Java hybrid, but has a 
fair bit in common with C# and C from a semantics perspective. VM 
performance in the JIT is roughly comparable to C#. it has existed in 
some form and been on/off updated and maintained since around 2004.

C-Aux, which is a bit newer and less mature, but is essentially just C 
in a VM. I had tried recently to get Quake working in the VM, but this 
effort had shaken up a lot of bugs (compiler / VM debugging is "fun") 
and problem areas (*1), and I haven't yet gotten back to beating on it (*2).

the VMs currently use very different bytecode representations, where BS 
uses a stack-based VM, and C-Aux uses a register-based VM.

*: one issue is how to best deal with function pointers into the VM 
within the constraints of a plain C implementation.

it is possible to use va_list, but this requires at least one "true" 
argument, and there is an issue that each function can only be used once 
(short of a way of reclaiming no-longer-needed function pointers).

however, this strategy fails hard for Win32 "stdcall" function pointers 
(which don't handle variable argument lists and assume callee stack 
cleanup), which come up in a few cases (Win32 event-handler callbacks).

I had been torn between either splitting up Quake such that parts of it 
are run in native land, or resort to implementing some sort of wrapper 
layer and making Quake use this (rather than try to directly interfacing 
between interpreted code and the Win32 API).

*2: much more of my time recently is going into my electronics projects, 
which only nominally involve programming (beating on the code which 
deals with I/O to the external electronics). had partly recently started 
on a real-time electronics simulator, but I would need to invest a bit 
more time in this as well (still pretty early in development).

this was prompted mostly by most of the existing free electronics 
simulators I can find not being terribly well suited to my uses (mostly 
frustrations with LTspice and Qucs and similar).

unlike some other simulators, this one uses a partial hybrid of 
board-layout and schematic symbols (it is not purely schematic, nor does 
it intend to full graphically represent a circuit board either, but is 
sort of a hybrid). for example, TO-92, TO-220, and TO-247 transistors 
have different representations and pin layout/spacing. it also attempts 
to simulate (thus far not so well) things like wire and component 
temperatures.

it is also intended mostly for DC power-electronics, which is more often 
what I am dealing with IRL. it may have some digital components, and 
basic support for analog electronics, but this wont be a focus. 
likewise, it uses a linear solver and simplistic models, which are 
faster but wont necessarily give high precision output. time-stepping is 
likely to be 100us for real-time (should be pretty doable for 
low-complexity circuits), smaller for reduced-time (say, 1s in real-time 
is mapped to 1ms in the simulation, and the simulator would operate on a 
100ns time-step).

I may or may not consider trying to simulate things like motors. could 
be a little harder, as things like 3-phase BLDC and induction motors' 
behavior depends a fair lot on the motor specifics, things like 
inductive properties in the phase coils, ... however, the model would 
still likely be mostly hand-waved (it would likely track the rotor 
position and velocity and dynamically change the induced current and 
reluctance as a result).

don't yet know if or to what extent scripting would be used in this 
(as-is, most component behavior is hard-coded). this would mostly apply 
if/when things like microcontrollers are simulated (probably C is 
compiled in a VM using a runtime based on a mockup of what is available 
for a given MCU, then the VM is run in-sync with the simulation).

to some extent, the idea is also influenced by things like FluidSIM and 
similar (which may simulate mixed electronic and pneumatic/hydraulic 
systems).

Thread

"Death To C" Lynn McGuire <lmc@winsim.com> - 2015-05-04 14:41 -0500
  Re: "Death To C" Melzzzzz <mel@zzzzz.com> - 2015-05-04 22:16 +0200
    Re: "Death To C" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-04 13:26 -0700
      Re: "Death To C" Melzzzzz <mel@zzzzz.com> - 2015-05-04 22:51 +0200
      Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-04 22:02 +0100
        Re: "Death To C" Melzzzzz <mel@zzzzz.com> - 2015-05-05 00:06 +0200
  Re: "Death To C" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-04 13:22 -0700
    Re: "Death To C" Melzzzzz <mel@zzzzz.com> - 2015-05-04 22:41 +0200
      Re: "Death To C" Robert Wessel <robertwessel2@yahoo.com> - 2015-05-04 20:25 -0500
        Bounds checking in C (Was: "Death To C") gazelle@shell.xmission.com (Kenny McCormack) - 2015-05-05 02:15 +0000
          Re: Bounds checking in C (Was: "Death To C") BGB <cr88192@hotmail.com> - 2015-05-06 10:23 -0500
        Re: "Death To C" Les Cargill <lcargill99@comcast.com> - 2015-05-04 21:36 -0500
          Re: "Death To C" Robert Wessel <robertwessel2@yahoo.com> - 2015-05-05 01:01 -0500
            Re: "Death To C" Les Cargill <lcargill99@comcast.com> - 2015-05-05 12:23 -0500
          Re: "Death To C" CHIN Dihedral <dihedral88888@gmail.com> - 2015-05-05 03:06 -0700
        Re: "Death To C" Ian Collins <ian-news@hotmail.com> - 2015-05-05 17:43 +1200
          Re: "Death To C" Robert Wessel <robertwessel2@yahoo.com> - 2015-05-05 01:00 -0500
            Re: "Death To C" Robert Wessel <robertwessel2@yahoo.com> - 2015-05-05 01:13 -0500
              Re: "Death To C" Ian Collins <ian-news@hotmail.com> - 2015-05-05 19:15 +1200
                Re: "Death To C" Robert Wessel <robertwessel2@yahoo.com> - 2015-05-05 02:41 -0500
                Re: "Death To C" Ian Collins <ian-news@hotmail.com> - 2015-05-05 20:12 +1200
        Re: "Death To C" glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-05 06:48 +0000
        Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-05 10:57 +0100
          Re: "Death To C" asetofsymbols@gmail.com - 2015-05-05 16:53 -0700
          Re: "Death To C" Nobody <nobody@nowhere.invalid> - 2015-05-06 08:10 +0100
            Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-06 09:53 +0100
              Re: "Death To C" Richard Heathfield <rjh@cpax.org.uk> - 2015-05-06 13:49 +0100
                Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-06 14:29 +0100
                Re: "Death To C" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-06 09:43 -0700
                Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-06 18:24 +0100
          Re: "Death To C" asetofsymbols@gmail.com - 2015-05-08 00:44 -0700
            Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-08 13:49 +0100
    Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-04 22:15 +0100
      Re: "Death To C" BGB <cr88192@hotmail.com> - 2015-05-08 09:09 -0500
    Re: "Death To C" Stephen Sprunk <stephen@sprunk.org> - 2015-05-04 16:18 -0500
    Re: "Death To C" Ian Collins <ian-news@hotmail.com> - 2015-05-05 12:49 +1200
  Re: "Death To C" raltbos@xs4all.nl (Richard Bos) - 2015-05-08 21:52 +0000
  Re: "Death To C" Merikissa <merikissa@no.spam.net> - 2015-05-10 04:04 +0300
  Re: "Death To C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-05-13 08:11 -0700
    Re: "Death To C" David Kleinecke <dkleinecke@gmail.com> - 2015-05-13 10:00 -0700
      Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-13 18:20 +0100
        Re: "Death To C" David Kleinecke <dkleinecke@gmail.com> - 2015-05-14 10:47 -0700
          Re: "Death To C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-05-14 11:09 -0700
          Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-15 19:21 +0100
            Re: "Death To C" David Kleinecke <dkleinecke@gmail.com> - 2015-05-16 09:10 -0700
              Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-16 20:45 +0100
                Re: "Death To C" David Kleinecke <dkleinecke@gmail.com> - 2015-05-17 09:38 -0700
        Re: "Death To C" raltbos@xs4all.nl (Richard Bos) - 2015-05-17 10:47 +0000
          Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-17 12:20 +0100
      Re: "Death To C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-05-13 10:24 -0700
        Re: "Death To C" David Brown <david.brown@hesbynett.no> - 2015-05-13 22:01 +0200
    Re: "Death To C" Nobody <nobody@nowhere.invalid> - 2015-05-14 07:48 +0100

csiph-web