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

Groups > comp.lang.c > #100369 > unrolled thread

Pine 64

Back to article view | Back to comp.lang.c

Contents

  Pine 64 jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-27 23:44 +0100
    Re: Pine 64 raltbos@xs4all.nl (Richard Bos) - 2016-12-27 22:54 +0000
      Re: Pine 64 jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-28 00:41 +0100
        Re: Pine 64 raltbos@xs4all.nl (Richard Bos) - 2016-12-28 12:14 +0000
      Re: Pine 64 David Brown <david.brown@hesbynett.no> - 2016-12-28 13:39 +0100
        Re: Pine 64 raltbos@xs4all.nl (Richard Bos) - 2016-12-28 12:45 +0000
          Re: Pine 64 David Brown <david.brown@hesbynett.no> - 2016-12-28 14:02 +0100
            Re: Pine 64 Keith Thompson <kst-u@mib.org> - 2016-12-28 10:11 -0800
              Re: Pine 64 Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-28 10:50 -0800
              Re: Pine 64 jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-28 22:55 +0100
                Re: Pine 64 David Brown <david.brown@hesbynett.no> - 2016-12-29 12:21 +0100
                  Re: Pine 64 jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-29 21:38 +0100
                    Re: Pine 64 David Brown <david.brown@hesbynett.no> - 2016-12-30 10:10 +0100
              Re: Pine 64 David Brown <david.brown@hesbynett.no> - 2016-12-28 21:53 +0100
              Re: Pine 64 raltbos@xs4all.nl (Richard Bos) - 2016-12-28 19:54 +0000
    Re: Pine 64 Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-12-27 18:03 -0500
      Re: Pine 64 jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-28 00:36 +0100
        Re: Pine 64 Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-12-27 18:44 -0500
          Re: Pine 64 jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-28 00:54 +0100
    Re: Pine 64 Noob <root@127.0.0.1> - 2016-12-28 11:27 +0100
      Re: Pine 64 jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-28 12:10 +0100
        Re: Pine 64 Noob <root@127.0.0.1> - 2016-12-28 12:59 +0100
    Re: Pine 64 Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-28 10:10 -0800
      Re: Pine 64 supercat@casperkitty.com - 2016-12-29 08:30 -0800
      Re: Pine 64 David Brown <david.brown@hesbynett.no> - 2016-12-29 13:22 +0100
        Re: Pine 64 Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-29 07:47 -0800
          Re: Pine 64 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-29 17:03 +0000
        Re: Pine 64 Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-29 04:50 -0800
          Re: Pine 64 Reinhardt Behm <rbehm@hushmail.com> - 2016-12-29 21:25 +0800
        Re: Pine 64 Keith Thompson <kst-u@mib.org> - 2016-12-29 09:28 -0800
        Re: Pine 64 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-29 14:22 +0000
      Re: Pine 64 David Brown <david.brown@hesbynett.no> - 2016-12-29 13:28 +0100
      Re: Pine 64 Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-28 14:12 -0800
        Re: Pine 64 BartC <bc@freeuk.com> - 2016-12-28 22:23 +0000
        Re: Pine 64 Gareth Owen <gwowen@gmail.com> - 2016-12-29 18:43 +0000
      Re: Pine 64 David Brown <david.brown@hesbynett.no> - 2016-12-28 21:59 +0100
      Re: Pine 64 jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-28 23:43 +0100
      Re: Pine 64 jt@toerring.de (Jens Thoms Toerring) - 2016-12-28 22:56 +0000
        Re: Pine 64 Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-28 16:00 -0800
          Re: A programming language called 'B64' Noob <root@127.0.0.1> - 2016-12-30 16:08 +0100

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

#100407

Le 28/12/2016 à 11:27, Noob a écrit :
> On 27/12/2016 23:44, jacobnavia wrote: [snip thoughts on arm64 SoC]
>
> Why don't you post these thoughts to your personal blog?
>

Good idea! Exactly what YOU should do noob. Those thoughts... keep them 
for yourself!

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

#100413

On 28/12/2016 12:10, jacobnavia wrote:
> Le 28/12/2016 à 11:27, Noob a écrit :
>> On 27/12/2016 23:44, jacobnavia wrote: [snip thoughts on arm64 SoC]
>>
>> Why don't you post these thoughts to your personal blog?
> 
> Good idea! Exactly what YOU should do noob. Those thoughts... keep them 
> for yourself!

Grammar tip: "keep them *to* yourself".

And just because there are a handful of ass-wipes in the group
posting all-noise-no-signal, it doesn't give you the right to
add to the noise with OT content.

comp.lang.c has never been anyone's personal blog.
(That goes for a few other posters.)

EOT

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

#100452

On Tuesday, December 27, 2016 at 10:44:22 PM UTC, jacobnavia wrote:
> 
> I bought one of their marvels, a small circuit, not much bigger than a 
> phone, with an arm64 quad core CPU, 2GB Ram, Linux, ethernet, and 
> everything you would need to ssh into it from my mac. The circuits 
> starts at 15 US$, but I invested more, and for around 30$ I bought a 
> transparent case, and the high end model with the 2Gigs.
> 
That's the way it's going to go. Those devices will be embedded 
everywhere, except in mass-market electronic products where you have
to shave every cent off the hardware costs, and there will
still be a market for very restricted processors.

It's a great opportunity to establish B64. The question is exactly 
how to define a 64 bit near-subset of C. 
  

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

#100496

On Thursday, December 29, 2016 at 9:47:52 AM UTC-6, Malcolm McLean wrote:
> No. A B64 interpreter would be easy enough to write, but I haven;t
> done it, largely because it needs a bit buffer description syntax.
> I also fret about whether we should have minimium types (reals,
> integers, strings and bit buffers) or just eliminate types altogether.

It is certainly useful to have a means of accessing packed collections of
smaller things, though it may be reasonable to say that pointers always
identify words, and all access to smaller things must be via intrinsics
which identify things using a word pointer and smaller-type offsets;
programs that don't need to access more than 32GB of storage might be able
to benefit from functions to load and store packed pointers that would
store an address shifted right three bits.  Even if a processor can operate
upon 64 bit pointers just as fast as 32-bit ones, any given amount of cache
will be able to hold twice as many 32-bit values or pointers as 64-bit ones.

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

#100505

On 28/12/16 23:12, Malcolm McLean wrote:
> On Wednesday, December 28, 2016 at 8:59:42 PM UTC, David Brown wrote:
>> On 28/12/16 19:10, Malcolm McLean wrote:
>>
>>> That's the way it's going to go. Those devices will be embedded
>>> everywhere, except in mass-market electronic products where you have
>>> to shave every cent off the hardware costs, and there will
>>> still be a market for very restricted processors.
>>>
>>
>> There is a very big gap between using a ready-made Linux ARM board and 
>> penny-counting hardware designs.  Boards like this are useful in small 
>> production runs, systems where time-to-market is of overwhelming 
>> importance, prototypes, and systems put together by amateurs (of which 
>> there are a great many).
>>
> So quite a lot. As the price falls, they become more and more the
> system of choice. As long as standards stick.

I don't think you have any idea what you are talking about - it would
make sense for you to simply accept that and drop the subject.  This is
not the place for details, especially as you have shown yourself
incapable of understanding similar issues in the past.

But just as a hint, there are embedded linux boards available for as
little as $10.  There are microcontrollers for $20 that have less than a
thousandth of the memory, and only a few percent of the processing
power.  Yet such microcontrollers sell in larger quantities than such
embedded Linux boards.  So either the entire electronics design and
production industry across the world are idiots, or there is more to
this topic than you understand.  Which do you think is more likely?

>>> It's a great opportunity to establish B64. The question is exactly
>>> how to define a 64 bit near-subset of C.
>>>
>>
>> No, it is not.  I am not sure what you think the market for B64 is, if 
>> even /you/ think there would be use for it anywhere.  But these sorts of 
>> boards are programmed in C, or using high level languages such as 
>> Python, Ruby, etc., depending on the type of application.
>>
> Virtually all the boards run embedded Linux, so you can say there is
> no room for a competitor there - Linux is the established standard,
> it does the job, you'd have to come up with something radically 
> better to compete.

There are lots of embedded boards running different systems - though
most that are 64-bit run Linux (either as "real" Linux, or as Android).

> 
> But we've got the opposite situation with languages. A long list.
> Which means that its high time something like B64 came along and
> provided a scaleable, interface-friendly, standardised method
> of programming computers.
> 

Most people see it as an advantage that there are a wide range of
programming languages to choose from, as different languages have their
strengths and weaknesses.

You, apparently, see it as a disadvantage.  And your grand solution for
your invented problem is ... wait for it ... to invent a /new/ language!
 And this vapourware language that exists only as vague ideas in your
own mind, is to be a new version of "B" - a language that only really
existed for about 2 or 3 years, nearly 50 years ago, before being
superseded by C.  But B64 will be the "scalable, interface-friendly,
standardised method of programming computers"!

You don't lack in ambition for your language, even if it lacks
everything else.

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

#100526

On Thursday, December 29, 2016 at 2:22:19 PM UTC, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
> There are modern typeless languages which would give a sound footing for
> a new one if nothing else, but I think Malcolm wants to go it alone.
>
No. A B64 interpreter would be easy enough to write, but I haven;t
done it, largely because it needs a bit buffer description syntax.
I also fret about whether we should have minimium types (reals,
integers, strings and bit buffers) or just eliminate types altogether.
>
> For example MCPL, derived from BCPL, is the result of about 5 decades of
> experience designing an using typeless languages for systems programming
> on everything from both small embedded devices and to mainframes.  It
> uses ML-style pattern matching to deconstruct data.
> 
MCPL looks like its worth a look.

"It is designed to be easy to learn and use, and easy to combine 
with C programs. Its simplicity results from its typelessness 
causing all expressions to yield values of the natural word size 
used in the implementation. This is usually 32 bits, but
on some machines a 64-bit word length could be used. Even though 
the language is typeless, convenient access to packed 8-bit 
characters is provided."

It's got most of the essentials of B64, except the 64.


This is hard to forgive however.

GET "mcpl.h"
FUN start
: => writef "Enter three lengths: "
LET a=readn(), b=readn(), c=readn()
writef("\nTriangle entered: %d %d %d", a, b, c)
writef("\nThis is %s triangle\n",
sort_of_triangle(a,b,c))
.
FUN sort_of_triangle
: a, b(<a), c => sort_of_triangle(b, a, c)
: a, b, c(<b) => sort_of_triangle(a, c, b)
// At this point we know that a <= b <= c
: a, b, >a+b => "not a"
: a, ?, =a => "an equalateral"
: a, =a, ? => "an isosceles"
: ?, =c, c => "an isosceles"
: a, b, c => c*c=a*a+b*b -> "a right angled",
"a scalene"

We need #include and curly braces to make it look a bit like C.
And return statements.

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

#100531

Note: I've set Followup-To: comp.programming because you never know...

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> On Thursday, December 29, 2016 at 2:22:19 PM UTC, Ben Bacarisse wrote:
<snip>
>> For example MCPL, derived from BCPL, is the result of about 5 decades of
>> experience
<snip>
> MCPL looks like its worth a look.
>
> "It is designed to be easy to learn and use, and easy to combine 
> with C programs. Its simplicity results from its typelessness 
> causing all expressions to yield values of the natural word size 
> used in the implementation. This is usually 32 bits, but
> on some machines a 64-bit word length could be used. Even though 
> the language is typeless, convenient access to packed 8-bit 
> characters is provided."
>
> It's got most of the essentials of B64, except the 64.

It works with 64-bit words so "MCPL with 64-bit words" could be your
starting point.

> This is hard to forgive however.
>
> GET "mcpl.h"
> FUN start
> : => writef "Enter three lengths: "
> LET a=readn(), b=readn(), c=readn()
> writef("\nTriangle entered: %d %d %d", a, b, c)
> writef("\nThis is %s triangle\n",
> sort_of_triangle(a,b,c))
> .
> FUN sort_of_triangle
> : a, b(<a), c => sort_of_triangle(b, a, c)
> : a, b, c(<b) => sort_of_triangle(a, c, b)
> // At this point we know that a <= b <= c
> : a, b, >a+b => "not a"
> : a, ?, =a => "an equalateral"
> : a, =a, ? => "an isosceles"
> : ?, =c, c => "an isosceles"
> : a, b, c => c*c=a*a+b*b -> "a right angled",
> "a scalene"
>
> We need #include and curly braces to make it look a bit like C.
> And return statements.

Who's "we"?  I don't need #include, and MCPL has curly braces and return
statements.

-- 
Ben.

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

#100537

On Thursday, December 29, 2016 at 12:22:37 PM UTC, David Brown wrote:
> On 28/12/16 23:12, Malcolm McLean wrote:
> 
> > So quite a lot. As the price falls, they become more and more the
> > system of choice. As long as standards stick.
> 
> I don't think you have any idea what you are talking about - it would
> make sense for you to simply accept that and drop the subject.  This is
> not the place for details, especially as you have shown yourself
> incapable of understanding similar issues in the past.
> 
> But just as a hint, there are embedded linux boards available for as
> little as $10.  There are microcontrollers for $20 that have less than a
> thousandth of the memory, and only a few percent of the processing
> power.  Yet such microcontrollers sell in larger quantities than such
> embedded Linux boards.  So either the entire electronics design and
> production industry across the world are idiots, or there is more to
> this topic than you understand.  Which do you think is more likely?
>
It's got all the signs of a world ripe for standardisation. Of course
individual actors are, for the most part, not stupid. That's not the
reason you get inefficient systems. 
>  
> Most people see it as an advantage that there are a wide range of
> programming languages to choose from, as different languages have their
> strengths and weaknesses.
> 
Exactly. As I said, the stupidity of the developers isn't the real
reason for lack of standardisation. Most programming languages do much
the same sort of thing, they just have different syntax for loops
and have a different way of describing variables. The plethora of
languages is a productivity catastrophe. The programming world is
ripe for standardisation.
>
> You, apparently, see it as a disadvantage.  And your grand solution for
> your invented problem is ... wait for it ... to invent a /new/ language!
>  And this vapourware language that exists only as vague ideas in your
> own mind, is to be a new version of "B" - a language that only really
> existed for about 2 or 3 years, nearly 50 years ago, before being
> superseded by C.  But B64 will be the "scalable, interface-friendly,
> standardised method of programming computers"!
> 
> You don't lack in ambition for your language, even if it lacks
> everything else.
>
The irony is that if we introduce B64, we've just added one language.
It can't be a strict subset of C because then the data description
syntax is not flexible enough. 

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

#100565

AT Thursday 29 December 2016 20:50, Malcolm McLean wrote:

> On Thursday, December 29, 2016 at 12:22:37 PM UTC, David Brown wrote:
>> On 28/12/16 23:12, Malcolm McLean wrote:
>> 
>> > So quite a lot. As the price falls, they become more and more the
>> > system of choice. As long as standards stick.
>> 
>> I don't think you have any idea what you are talking about - it would
>> make sense for you to simply accept that and drop the subject.  This is
>> not the place for details, especially as you have shown yourself
>> incapable of understanding similar issues in the past.
>> 
>> But just as a hint, there are embedded linux boards available for as
>> little as $10.  There are microcontrollers for $20 that have less than a
>> thousandth of the memory, and only a few percent of the processing
>> power.  Yet such microcontrollers sell in larger quantities than such
>> embedded Linux boards.  So either the entire electronics design and
>> production industry across the world are idiots, or there is more to
>> this topic than you understand.  Which do you think is more likely?
>>
> It's got all the signs of a world ripe for standardisation. Of course
> individual actors are, for the most part, not stupid. That's not the
> reason you get inefficient systems.
>>  
>> Most people see it as an advantage that there are a wide range of
>> programming languages to choose from, as different languages have their
>> strengths and weaknesses.
>> 
> Exactly. As I said, the stupidity of the developers isn't the real
> reason for lack of standardisation. Most programming languages do much
> the same sort of thing, they just have different syntax for loops
> and have a different way of describing variables. The plethora of
> languages is a productivity catastrophe. The programming world is
> ripe for standardisation.

SO want to have a 64-bit CPU in your keyboard and in your mouse, each with 
2GB of RAM and flash?
I buy a mouse here in TW for 1US$. With your "standardisation" it would cost 
50$ and be to heavy to use.

>>
>> You, apparently, see it as a disadvantage.  And your grand solution for
>> your invented problem is ... wait for it ... to invent a /new/ language!
>>  And this vapourware language that exists only as vague ideas in your
>> own mind, is to be a new version of "B" - a language that only really
>> existed for about 2 or 3 years, nearly 50 years ago, before being
>> superseded by C.  But B64 will be the "scalable, interface-friendly,
>> standardised method of programming computers"!
>> 
>> You don't lack in ambition for your language, even if it lacks
>> everything else.
>>
> The irony is that if we introduce B64, we've just added one language.
> It can't be a strict subset of C because then the data description
> syntax is not flexible enough.

No we don't need any vaporware for programming.

-- 
Reinhardt

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

#100547

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
[...]
> B actually did have a life of it's own after C, though I agree it was
> specialised and relatively short-lived.
>
> I may be unique here in having written an actual program in B.
[...]

Not *quite* unique.

https://github.com/Keith-S-Thompson/fizzbuzz-polyglot/blob/master/fizzbuzz.b

(BCPL is on my TODO list.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#100590

David Brown <david.brown@hesbynett.no> writes:
<snip>
> Most people see it as an advantage that there are a wide range of
> programming languages to choose from, as different languages have their
> strengths and weaknesses.
>
> You, apparently, see it as a disadvantage.  And your grand solution for
> your invented problem is ... wait for it ... to invent a /new/ language!
>  And this vapourware language that exists only as vague ideas in your
> own mind, is to be a new version of "B" - a language that only really
> existed for about 2 or 3 years, nearly 50 years ago, before being
> superseded by C.

B actually did have a life of it's own after C, though I agree it was
specialised and relatively short-lived.

I may be unique here in having written an actual program in B.  As a
teenager in the late '70s, I wanted to write a chess program and B
seemed like the best choice on the Honeywell mainframe I had access to.
As I recall, there were quite a system utilities on that machine were
written in B, but that may only have been local customisation.

It would be a hoot to look at that chess program now -- what a mess it
must have been.  It moved with me from house to house, along with all
sorts of other ancient programs, on a 9-track tape but at some point it
just got lost.

> But B64 will be the "scalable, interface-friendly,
> standardised method of programming computers"!
>
> You don't lack in ambition for your language, even if it lacks
> everything else.

There are modern typeless languages which would give a sound footing for
a new one if nothing else, but I think Malcolm wants to go it alone.

For example MCPL, derived from BCPL, is the result of about 5 decades of
experience designing an using typeless languages for systems programming
on everything from both small embedded devices and to mainframes.  It
uses ML-style pattern matching to deconstruct data.

-- 
Ben.

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

#100512

On 28/12/16 23:23, BartC wrote:
> On 28/12/2016 22:12, Malcolm McLean wrote:
>> On Wednesday, December 28, 2016 at 8:59:42 PM UTC, David Brown wrote:
>>> On 28/12/16 19:10, Malcolm McLean wrote:
> 
>>> No, it is not.  I am not sure what you think the market for B64 is, if
>>> even /you/ think there would be use for it anywhere.  But these sorts of
>>> boards are programmed in C, or using high level languages such as
>>> Python, Ruby, etc., depending on the type of application.
>>>
>> Virtually all the boards run embedded Linux, so you can say there is
>> no room for a competitor there - Linux is the established standard,
>> it does the job, you'd have to come up with something radically
>> better to compete.
> 
> But Linux == C for most practical purposes.

Really?  That will be news to most people who program in C, as well as
most people who program for Linux.  Certainly there is a strong
connection between the C language and nix-like operating systems, but it
is /very/ far from equality.

> 
>> But we've got the opposite situation with languages. A long list.
>> Which means that its high time something like B64 came along and
>> provided a scaleable, interface-friendly, standardised method
>> of programming computers.
> 
> If you had to distribute a source code app to run on Linux, the best bet
> would be C or Python. C if it had to be low-level or fast.

For the lowest level code, or the most efficient code, while maintaining
maximal portability - then C is the answer.  But you can get a lot of
portability with other languages as well as Python (though Python is
often a good choice) - Perl, PHP, Ruby, C++, ocaml, lua, Fortran, Ada,
Bash, and many other languages are reasonably popular and portable.

> 
> B64 is more of a problem since it's unlikely any random Linux system
> will have a compiler for it already installed.

It is unlikely that any system at all will have a compiler for it - it
does not exist.

> 
> But all the tools people have will be geared up for the mainstream
> languages (syntax-highlighting for one).
> 
> Introducing a new language has a lot of problems, even apart from
> persuading people to use it.
> 

Yes indeed.

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

#100518

On Wednesday, December 28, 2016 at 8:59:42 PM UTC, David Brown wrote:
> On 28/12/16 19:10, Malcolm McLean wrote:
> 
> > That's the way it's going to go. Those devices will be embedded
> > everywhere, except in mass-market electronic products where you have
> > to shave every cent off the hardware costs, and there will
> > still be a market for very restricted processors.
> >
> 
> There is a very big gap between using a ready-made Linux ARM board and 
> penny-counting hardware designs.  Boards like this are useful in small 
> production runs, systems where time-to-market is of overwhelming 
> importance, prototypes, and systems put together by amateurs (of which 
> there are a great many).
> 
So quite a lot. As the price falls, they become more and more the
system of choice. As long as standards stick.
>
> > It's a great opportunity to establish B64. The question is exactly
> > how to define a 64 bit near-subset of C.
> >
> 
> No, it is not.  I am not sure what you think the market for B64 is, if 
> even /you/ think there would be use for it anywhere.  But these sorts of 
> boards are programmed in C, or using high level languages such as 
> Python, Ruby, etc., depending on the type of application.
>
Virtually all the boards run embedded Linux, so you can say there is
no room for a competitor there - Linux is the established standard,
it does the job, you'd have to come up with something radically 
better to compete.

But we've got the opposite situation with languages. A long list.
Which means that its high time something like B64 came along and
provided a scaleable, interface-friendly, standardised method
of programming computers.

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

#100530

On 28/12/2016 22:12, Malcolm McLean wrote:
> On Wednesday, December 28, 2016 at 8:59:42 PM UTC, David Brown wrote:
>> On 28/12/16 19:10, Malcolm McLean wrote:

>> No, it is not.  I am not sure what you think the market for B64 is, if
>> even /you/ think there would be use for it anywhere.  But these sorts of
>> boards are programmed in C, or using high level languages such as
>> Python, Ruby, etc., depending on the type of application.
>>
> Virtually all the boards run embedded Linux, so you can say there is
> no room for a competitor there - Linux is the established standard,
> it does the job, you'd have to come up with something radically
> better to compete.

But Linux == C for most practical purposes.

> But we've got the opposite situation with languages. A long list.
> Which means that its high time something like B64 came along and
> provided a scaleable, interface-friendly, standardised method
> of programming computers.

If you had to distribute a source code app to run on Linux, the best bet 
would be C or Python. C if it had to be low-level or fast.

B64 is more of a problem since it's unlikely any random Linux system 
will have a compiler for it already installed.

But all the tools people have will be geared up for the mainstream 
languages (syntax-highlighting for one).

Introducing a new language has a lot of problems, even apart from 
persuading people to use it.

-- 
Bartc

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

#100583

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> But we've got the opposite situation with languages. A long list.
> Which means that its high time something like B64 came along and
> provided a scaleable, interface-friendly, standardised method
> of programming computers.

https://xkcd.com/927/

But I'll tell you what - get 3 more people to contribute code to B64
and maybe, just maybe, people might consider starting to perhaps take it
slightly seriously as the "next C", when compared to Go, Swift, Rust etc

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

#100520

On 28/12/16 19:10, Malcolm McLean wrote:
> On Tuesday, December 27, 2016 at 10:44:22 PM UTC, jacobnavia wrote:
>>
>> I bought one of their marvels, a small circuit, not much bigger than a
>> phone, with an arm64 quad core CPU, 2GB Ram, Linux, ethernet, and
>> everything you would need to ssh into it from my mac. The circuits
>> starts at 15 US$, but I invested more, and for around 30$ I bought a
>> transparent case, and the high end model with the 2Gigs.
>>
> That's the way it's going to go. Those devices will be embedded
> everywhere, except in mass-market electronic products where you have
> to shave every cent off the hardware costs, and there will
> still be a market for very restricted processors.
>

There is a very big gap between using a ready-made Linux ARM board and 
penny-counting hardware designs.  Boards like this are useful in small 
production runs, systems where time-to-market is of overwhelming 
importance, prototypes, and systems put together by amateurs (of which 
there are a great many).

> It's a great opportunity to establish B64. The question is exactly
> how to define a 64 bit near-subset of C.
>

No, it is not.  I am not sure what you think the market for B64 is, if 
even /you/ think there would be use for it anywhere.  But these sorts of 
boards are programmed in C, or using high level languages such as 
Python, Ruby, etc., depending on the type of application.

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

#100548

Le 28/12/2016 à 19:10, Malcolm McLean a écrit :

> It's a great opportunity to establish B64. The question is exactly
> how to define a 64 bit near-subset of C.
>
>

A 64 bit counter ticking at 1MHZ overflows after half a million years.

The same counter in 32 bits overflows after an hour or so...

Many diemnsioning problems just disappear using wide integers.

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

#100563

Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
> On Tuesday, December 27, 2016 at 10:44:22 PM UTC, jacobnavia wrote:
> > 
> > I bought one of their marvels, a small circuit, not much bigger than a 
> > phone, with an arm64 quad core CPU, 2GB Ram, Linux, ethernet, and 
> > everything you would need to ssh into it from my mac. The circuits 
> > starts at 15 US$, but I invested more, and for around 30$ I bought a 
> > transparent case, and the high end model with the 2Gigs.
> > 
> That's the way it's going to go. Those devices will be embedded 
> everywhere, except in mass-market electronic products where you have
> to shave every cent off the hardware costs, and there will still be
> a market for very restricted processors.

True - why (even when not considering costs) a put a gigantic
processor with GBs of memory in something that will do nicely
with a 32-bit processor, running at say 200 MHZ, and never
needing more than 32 MB of memory? (I'm just rogramming for
such a system, and its's still overspeked, using less than
half the memory and less 1% of the available CPU time, 99.9%
of it waiting for anything to happen;-)

> It's a great opportunity to establish B64. The question is exactly 
> how to define a 64 bit near-subset of C. 

I may be a bit stupid, but what does 'B64; stand for? And what
kind of  "subset of C" are you writing about?

The arrival of these cheap and "small" systems (from the modern
point of view - two decades ago they'd have been marketed as
"workstations";-) is indeed a good thing in allowing people
to get their hands dirty on low level stuff, something hardly
anyone would dare to do on his/her "main" machine. And good
for C since it's the "lingua franca" in these environments.

                              Regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

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

#100603

On Wednesday, December 28, 2016 at 10:56:25 PM UTC, Jens Thoms Toerring wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
> > On Tuesday, December 27, 2016 at 10:44:22 PM UTC, jacobnavia wrote:
> > > 
> > > I bought one of their marvels, a small circuit, not much bigger than a 
> > > phone, with an arm64 quad core CPU, 2GB Ram, Linux, ethernet, and 
> > > everything you would need to ssh into it from my mac. The circuits 
> > > starts at 15 US$, but I invested more, and for around 30$ I bought a 
> > > transparent case, and the high end model with the 2Gigs.
> > > 
> > That's the way it's going to go. Those devices will be embedded 
> > everywhere, except in mass-market electronic products where you have
> > to shave every cent off the hardware costs, and there will still be
> > a market for very restricted processors.
> 
> True - why (even when not considering costs) a put a gigantic
> processor with GBs of memory in something that will do nicely
> with a 32-bit processor, running at say 200 MHZ, and never
> needing more than 32 MB of memory? (I'm just rogramming for
> such a system, and its's still overspeked, using less than
> half the memory and less 1% of the available CPU time, 99.9%
> of it waiting for anything to happen;-)
> 
Most modern software does a basic calculation which is trivial.
For example, a spreadsheet may need to add up a hundred numbers.
The user uses software rather than doing it by hand for one
reason and one reason alone - it's faster by computer.

However he's probably running the spreadsheet on a 2GHz
machine. The basic loop that does the addition is only one 
tiny part of the program. And the program is embedded in a
sophisticated operating system. Now if we were resource
constrained, we could implement the whole thing on ZX81
with 16K of memory. But it's easier to have a standard 
computer that can do anything, even if most jobs it actually
does are like our spreadsheet operation.
>
> > It's a great opportunity to establish B64. The question is exactly 
> > how to define a 64 bit near-subset of C. 
> 
> I may be a bit stupid, but what does 'B64; stand for? And what
> kind of  "subset of C" are you writing about?
> 
B stands for the letter before C, so it's a simplification of
C, a near subset. 64 stands for 64 bits, because all types will
be 64 bits in size, it's designed for processors which have 64 
bit registers.
>
> The arrival of these cheap and "small" systems (from the modern
> point of view - two decades ago they'd have been marketed as
> "workstations";-) is indeed a good thing in allowing people
> to get their hands dirty on low level stuff, something hardly
> anyone would dare to do on his/her "main" machine. And good
> for C since it's the "lingua franca" in these environments.
> 
Yes, a 64 bit machine is now available for 15 dollars, according 
to Jacob, admittedly all you get is the basic main card. Let's
hope that figure continues to come down, at the moment it's still
an expensive component in consumer electronics terms - an MP3
player costs about 20 - 100 pounds, for example, so including 
the board would dominate the price. It needs to come down to 
about 5 dollars (a dedicated MP3 chip costs 4 dollars or so
for runs of half a million). But then it will run an MP3 decoder
and have capacity to spare for the control system and tunes
management.
But is C the language to program something like that in?

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

#100664 — Re: A programming language called 'B64'

On 29/12/2016 01:00, Malcolm McLean wrote:

> Jens Thoms Toerring wrote:
>
>> what does 'B64; stand for?
>
> B stands for the letter before C, so it's a simplification of
> C, a near subset. 64 stands for 64 bits

FTR, plain 'B' already exists, it was C's ancestor.

https://en.wikipedia.org/wiki/B_%28programming_language%29

[toc] | [prev] | [standalone]

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

Back to top | Article view | comp.lang.c

csiph-web