news:k3jrq8$euv$1@speranza.aioe.org...

Agreed.

Are you volunteering to re-write the policy?  If so, then have at it.

No.  The "red flags" were *your* response to Hugh's post and Wolfgang's
response to Hugh's post.  I just "naturally" grabbed for the fire
extinguisher (knowing the history of anti-HLA rummblings around these
parts). ;)

No.
Sometimes, to "drive a yellow taxi" requires an agency to check on things.
Naturally, I have no idea how far in-depth that goes.
Sometimes, one has 'several' too many sips from the hard-cider jug.
Sometimes, I really do feel like I live the life of a character from a
Michael Crichton or Tom Clancy novel.

Anyway, since I am once again posting OFF-TOPIC, you will notice that I have
cross-posted to ALA and set followups to there.

Nathan.

news:SbudnYYEF-6xisPNnZ2dnUVZ_g2dnZ2d@giganews.com...

On CLAX, you said:

I haven't seen a post from Randall in five or so years.  Could you tell me
where he posted that?  Was that on CLAX or somewhere else?

If he's going to do that, he'd definately want to know how to implement a
threaded-code interpreter, in early Forth-style.  Although somewhat
difficult to get information on in non-Forth terms, it's a very effective
interpreter design.  I've been thinking about re-using my Forth interpreter
without the Forth language.

His statements definately lends some credence to what I said on CLAX
recently, and a few years ago on ALA.

Me recently on comp.lang.asm.x86:
RP> IMO (FYI, negative), HLA is a botched up version of C with Pascal style
RP> parts.  It's a high level language.  It's not assembly.

Me a few years ago on alt.lang.asm:
RP> In summary, the primary constraint of HLA as a teaching tool has
RP> resulted in an obtuse syntax which obstructs integration of HLA
RP> into any single high level language such as C or Pascal.  Therefore,
RP> HLA is useless outside academia since it fails to solve any real world
RP> problem of high level languages.  Have I got that correct?

On CLAX?  With Chuck?  Before you and Frank took control?  No way.

After you and Frank took control?  That seems highly unlikely too ...

I think the discussions you remember was right here on alt.lang.asm circa
2006 and 2007.

Randall Hyde's incessant pro-HLA posts, versus everyone else including
the notorious Betov and his RosAsm.

Wait, there are two taxi drivers on CLAX?  You and Hugh?  ;-)
I won't take that literally unless you say so ...

Fingerprints as a condition of employment are typically for:
1) securities and banking industries
2) secret and top secret government clearances
3) law enforcement positions

Of course, for non-employment situations, any agency with the authority to
arrest, and sometimes detain, can do so.

Rod Pemberton

   [Fup2 set to ALA -- this may be OT for clax86]
Hugh Aguilar <hughaguila...@nospicedham.yahoo.com> wrote in part:

May I politely suggest you are asking the wrong question?

As others have posted, x86-64bit hardware is common, verging on
inescapable.  Software is a whole separate question.  In view of
the large software library, 32bit support will be around for a
very long time -- at least as long as 16bit is/was -- since the
necessity and advantages of 64 bit (addr.space) are less often
compelling than 32 bit vs 16 bit.

A better question is x86 versus ARM .  Many people are abandoning
laptops in favor of smartphones and tablets as their primary
computing device; stronger than their migration from desktops to
laptops.  Portibility is a decisive advantage and there are others.

While there likely will be a server / bigbox future for x86 for
the foreseeable future, user computers and the important economies of
scale they bring will shift to ARM unless x86 mfrs (Intel, AMD) can
bring their electric power consumption down very substantially.

I have a very nice Intel Atom D525 system, but it draws 21W .
I also have an Raspberry Pi (ARM) that draws about 4W .  Sure,
the Atom is much faster, but the RPi is fast enough to handle the
most CPU intensive task for most users (MPEG4 decompression).

If Intel and/or AMD can scale x86 back to ARM power consumption,
then they will have a chance at the mobile market, and we asm
coders will have our work cut out to maximize performance (likely
with very different x86 optimization guides).

-- Robert

On Sep 23, 6:51 am, Robert Redelmeier <red...@ev1.net.invalid> wrote:

You may be right that the x86 has a diminished future. I remember when
the PowerPC came out that it was significantly better than the 80486.
Many people said that CISC was a dead-end and that the x86 was
circling the drain, and the future belonged to RISC. Then the Pentium
came out and killed the PowerPC. Apparently the PowerPC never attained
critical-mass in regard to mass usage, and hence there wasn't enough
money available to pay for the R&D on developing a better PowerPC that
could compete with the Pentium. AFAIK however, there is nothing wrong
with the PowerPC architecture that would prevent faster and faster
versions from coming out. The argument is still true that RISC is
better than CISC. The x86 devotes a lot of resources to recompiling
CISC code into RISC code at run-time --- it would really be more
efficient to do this at compile-time.

The ARM certainly has critical-mass, so maybe there will be
increasingly fast versions of the ARM coming out that eventually make
it a reasonable choice for laptops. I agree though that the 64-bit x86
has a pretty solid hold on the big-computer market. If you need more
than 4GB of memory, that is pretty much the only choice (there is the
DEC Alpha, but it seems to be nowhere near critical-mass). The ARM
seems like an unlikely choice for laptops however, considering that it
is designed for micro-controllers. The whole point of those register
banks is to boost the speed of ISRs, and this is a micro-controller
issue. The ARM might yet take over the laptop market though! Power
consumption is certainly an issue --- it is really hard to find an AC
plug-in for a laptop --- my laptop would be a lot more useful to me if
I could just rely on the battery all day and only plug it in at night
to recharge.

If the ARM did become an option for low-power laptops, would they
necessarily run Linux? AFAIK, Microsoft is committed to the x86. For
that matter, isn't Linux gaining a lot of traction for servers running
on 64-bit x86? Does Windows have a future?

BTW, on a related note --- Vista has recently crashed on my laptop.
Now it just hangs in the log-in screen. I don't know how to fix this.
I restored the registery to prior to the last two installs that I did
(Java and Adobe), but that didn't help. I ran System Mechanic, but
that didn't help. Right now I'm running in Safe Mode and I don't know
how to solve the problem. This happened on my old laptop too, and I
couldn't solve it --- I just turned the computer into a pure-Linux box
and bought this laptop for running Windows. If I can't fix the problem
I'll install Menuet on top of Windows and buy yet another laptop to
run Windows. I don't want to reinstall Windows because that will wipe
out my Linux partition --- AFAIK, a Windows install always wipes out
every other OS and takes over the entire hard drive. I'm getting
really ticked off at Microsoft --- they make a ton of money, and they
continue to deliver garbage! How long can this go on?

On Sep 23, 6:51 am, Robert Redelmeier <red...@ev1.net.invalid> wrote:

Is there a significant difference between the power consumption of the
32-bit and 64-bit x86? Maybe in the future laptops will be 32-bit to
boost battery life and desktop-computers will be 64-bit to boost
performance. This is the scenario that I was thinking of when I first
posted my question. You may be right though that the ARM will take
over the laptop market and the 32-bit x86 will just get phased out
altogether, leaving 64-bit x86 for the desktop-computers and the
performance-oriented laptops.

One good thing about the ARM moving into the laptop market, would be
that the same development tools (and the same developers) would be
able to move back and forth between the micro-controller and laptop
worlds. The ARM would become the ubiquitous platform everywhere --- as
Joseph Stalin said: "Quantity has a quality of its own."

On Sep 23, 4:11 am, "Rod Pemberton" <do_not_h...@notemailnotz.cmm>
wrote:

Somewhere else:  aoaprogramming group on Yahoo.

Yes, I was thinking of ALA when I said "around these parts" ...
meaning: in this same corner (vicinity) of UseNet.

4) hazardous materials

I have discovered that certain industries provide compelling
entertainment for us bored autodidacts.  Research satisfies the inner
sleuth.

Nathan.

On Sep 23, 10:13 pm, Nathan <nathancba...@gmail.com> wrote:

I heard that he is working on an HLL language as described above.

He also said, however, that he is going to release an upgraded version
of HLA pretty soon --- I don't know what the upgrade will involve ---
64-bit support seems too much to hope for.

Working with children under the age of 12 --- cab drivers have to get
fingerprinted and go through a background check to transport children
without a guardian along. This is most likely true of any job that
involves being alone with other people's children.

I don't transport children. I don't do vouchers at all anymore --- I
can't stand those welfare recipients --- "welfarocrats" is my coined
term for them.

news:cf66d94a-c31e-45d6-8e5d-8e49e963bbdf@rg9g2000pbc.googlegroups.com...

They're typically needed for a concealed weapons permit too...  In the
context of a job, that'd probably be under 3) or other security work.

I was aware of licensing - but not the fingerprinting - for demolition,
pyrotechnics, fireworks, ammunition, etc.  It seems those, or some of them,
require fingerprints too.  If we start looking, we might find a whole bunch
of jobs that require them.  I can see the government wanting them for
certain jobs in the chemical industry, or nuclear industry.

It's possible they may even require fingerprints for a few jobs in the food
industry.  The US food industry processes raw coca leaves on US soil.  I bet
you didn't know that.  A Federal license is required for a company to import
and process them.  AIR, only one US company is licensed for it, and it's the
only company that ever has been licensed.  I.e., they've been a US
government guaranteed monopoly for over a century now, since no other
company can get a license.  I bet you thought monopolies were illegal under
US law too ...  They are ... except when the US governement gets involved.
Yes, the processing of the coca leaves produces exactly the white powder
substance you think it is, and it's being _legally_ produced in the US,
under Federal law, on US soil ...  The non-food product from the coca leaves
is sold as food grade anesthetic.  The medical product company's which buy
the food grade version of the white powder product must be licensed too.
They convert it from food grade to medical grade for plastic surgery on the
nose (no joke).  I.e., it's the same place the illegal version of the
product typically goes!  AIR, there were two of them.  The food product:
de-chemicalized, coca leaves, are sold to the world's largest beverage
company for their flagship, fizzy, soda-pop, cola product.  Another cola
product, which "gives you wings", uses processed leaves from Germany, which
apparently removes less of the otherwise illegal substance ... hence the
saying.  Since the leading beverage uses a massive amount of leaves, we're
likely producing massive amounts of legal white powder.  No, I have no idea
what they do with the surplus.  It might be destroyed or converted to some
other chemicals.  If legalized, it'd probably be enough to immediately halt
all imports of the illegal stuff into the US.  I.e., a simple change of US
law would end the the Columbian drug wars and the fight with Mexican drug
lords.  I'm not for legalizing drugs, but the cost of keeping them illegal
is immense in terms of money, lives, time, and other resources.  The funds
could be funding socialized healthcare, feeding our poor, educating our
children.  Instead we waste it on locking people up or keeping them out.
It's a fruitless solution.

Interesting ...  That's most likely a state law.

I wonder if that's true of flight attendants or airplane pilots which land
or fly across the States?  The airline industry flies children without their
parents.  Public school buses transport without parents too.

I guess the airline flights and school buses probably don't qualify as
transporting a child "alone" ...

Rod Pemberton

On 9/23/2012 8:51 PM, Hugh Aguilar wrote:

AFAIK, there is no real significant power-usage difference between
32-bit and 64-bit CPUs.

this is presumably part of why newer versions of the Intel Atom have
64-bit support as well.

much more depends on the code itself, like people would start having to
write more apps that have smaller memory footprints and spend more of
their time sleeping (basically, apps that mostly just sleep and "wake
up" mostly to handle user-input, rather than, say, just spinning in the
main loop at full speed).

for some "lightweight" games, it may be possible to use framerate
limiting to save power, but this doesn't work with games which require
considerably more processing and GPU power (IOW: a person can likely get
good battery life from a sanely written 2D platformer or similar, but
probably not from something more along the lines of Doom3).

I wouldn't want to see more ARM.
at the ISA level, ARM is messier and nastier than x86.

better would be if x86 moves into being used in more tablets and
cellphones, but this mostly means better scaling back power use, and
allowing more OEM level customization.

better I think would be if 3rd parties could also make their own x86
chips (using the full/modern form) without risk of patent issues.

(at this point, it would mostly be limited to something more 386 or 486
like).

granted, this may not require specific hardware, for example, a
developer could be using RISC style hardware, but run x86 code more via
emulation (more like what Transmeta was doing...).

...

If it ain't broke, don't fix it. Bill Gates got his start selling BASIC
that wasn't written yet to MITS, and he's been selling software that
wasn't written yet ever since.

We were discussing - can't find the exact message - the likelihood of
128/256 bit registers? I just read a message on the Nasm developer's
list from the maintainer of Vector Pascal, asking about a Nasm upgrade
for Xeon Phi. I googled it, and rather than read the Intel ads, found
this about what's wrong with it:

http://www.brightsideofnews.com/news/2012/7/13/xeon-phi-lacks-binary-...

32 512-bit registers, apparently. Of course, just because Intel released
it doesn't mean it will fly. My observation is that "the market" doesn't
want your shiny new CPU if it won't run our clunky old apps, no matter
how good it is! We shall see... I don't know anything about it, just
thought I'd mention it...

Best,
Frank

On Mon, 24 Sep 2012 16:56:29 -0400

As I see this card tend to compete with GPU cards at parallel computing,
except that it is not GPU. Main problem with it is not as
incompatibility with MMX/SSE/AVX, rather that it's SIMD instruction set
will not be compatible with regular x86 processors. As if one
writes/compiles for Xeon Phi, same program will not run on any other
x86 processor. Given that and that everyone gets GPU card  (and
similar capability) for lower price, I don;t see any bright future
for this....

--
drwxr-xr-x 2 bmaxa bmaxa 4096 Sep 23 21:18 .

On Sep 24, 10:23 am, BGB <cr88...@hotmail.com> wrote:

Can you elaborate on the "messier and nastier than x86" comment?

I don't actually program the ARM, but I have read a book on the
assembly language and it looked pretty cool. My impression of the
general concensus among programmers is that the ARM is wonderful ---
that is why it became ubiquitious in the micro-controller world.

Of course, the x86 is ubiquitous in the desktop-computer world and I
don't think it is very wonderful --- apparently many do though.

The ARM was originally designed as a replacement for the 65c02 in the
Acorn with a heavy emphasis on fast interrupt response. It seems to
have pretty much nailed that problem, with a huge block of registers
getting swapped automatically. The PIC24 does something similar, with
4 registers swapped. It is common in micro-controller programs to
spend over 50% of the time in ISRs.

On Mon, 24 Sep 2012 21:16:37 -0700 (PDT), Hugh Aguilar

Ugh.  Nobody, but nobody, who matters cares how nice the ISA is or
isn't.  ARM has taken over a huge chunk of the embedded world by
providing CPUs with excellent performance per watt, low die size
requirements, licensing, availability of a multitude of
implementations, excellent toolchain support and easy licensing. Other
than excellent toolchain support, the current x86 world matches none
of those.  THE ISA has/had approximately nothing to do with it.

x86 delivers outstanding performance (in absolute terms, no less) for
an excellent price. Software compatibility is another huge win for
x86.  Performance per watt, is not the architecture's strong suit, but
the interesting question is how much of that is due to the ISA as
opposed to the implementations (which for decades have emphasized
performance above all else).  Again the ISA matters little.  The ISA
encoding, even less.

It will be an interesting few years as x86 pushes down the power
consumption curve, and ARM pushes up the performance curve.  Both ISAs
have considerable software and toolchain support, although their
applications largely don't overlap at the moment.

Sure, that was an issue for early (and current very small) ARMs.  It's
a non-issue at the higher end.  The 64 bit ARM ISA does away with most
of that.  And the ARM 64 bit ISA is rather radically different than
ARM32 (much more traditional RISC).

On 9/24/2012 11:16 PM, Hugh Aguilar wrote:

no...

it is mostly low power usage and the ability of OEMs to customize the
die, because typically ARM chips are fabricated by the OEM rather than
by ARM. in contrast, Intel or AMD will sell a pre-made chip.

however, the ISA (especially Thumb and Thumb2) is a bit-twiddly mess,
IMO considerably worse than x86.

because, despite its kludges, x86 at least has a vaguely consistent set
of rules for encoding instructions.

nevermind things like the ISA and overall architecture not being
terribly consistent between one ARM chip and another, meaning ASM code
will have to be more aware of the specific ARM chip it is targeting to
know which instructions it can use, ...

these things are a bit worse from a compiler-and-tools perspective, as
well as a "just keep running old software and have it still work"
perspective.

so, there ends up being some need for VMs (and JITs) mostly to allow
apps to be binary compatible between different devices running different
ARM chips.

the x86 ISA is at least "moderately" decent (and, nevermind the prefix
mess, the instruction encoding rules are relatively consistent as well).

performance is also fairly good.

and, at least it isn't featuring significant (not backwards compatible)
architectural changes from one version to the next.

can't say, but this is more for small end...

by the time someone is looking at something the scale of a smartphone or
tablet, this is getting much closer to the bigger "laptops and PCs"
use-case, for which ARM seems like a worse offering than x86.

they are an outgrowth of cellphones, but have moved from the use-case of
what cellphones were originally, to being more like that of a computer.
the optimal cost/benefit tradeoffs tend to shift with such a conversion.

some of the other purported "benefits" are actually more due to software:
ARM devices have tended to run very minimal and stripped-down OS's and
software, meaning that the resource requirements are much less.

this could also be done with x86.
however, people are typically going the other way, putting increasingly
heavy-weight OS's and software on ARM devices, meaning that the relative
"benefit" will become less.

the one major thing still in favor of ARM is battery life.

usually, this isn't as much of an issue for PCs or laptops, since they
are usually run plugged into the wall (and AFAICT the main
power-consumers in a laptop tend to be the LCD backlight and HDD anyways).
(there can be a significant gain in battery life mostly by turning down
the screen brightness and setting the HDD to spin down faster).

in netbooks and similar, it is more common to use a Flash SSD drive or
similar, instead of a platter-based HDD, and to use smaller screens with
less need of a big backlight. this also helps.

or such...

news:k3n3ag$pud$1@speranza.aioe.org...

[set back to cross-post because, yeah it ventures off-topic, but x86'ers
need to face these realities at some point anyway... so why not chat about
it for a bit?  In fact, if there is interest, I'd entertain setting-up
alternative UseNet groups]

Indeed.  I can recommend the newest StraightTalk as a gentle/cheap
introduction.  [some of these specs/reviews may be a bit dated]

http://www.lg.com/us/cell-phones/lg-L75C-optimus-zip
http://www.phonearena.com/news/LG-Optimus-Zip-brings-entry-level-Andr...
http://www.youtube.com/watch?v=j5X8JtG99aE
http://www.android.gs/tracfone-lg-optimus-zip-specs-features/

It **almost** represents a full-fledged desktop computer shrunk-down into an
extremely compact form.  The Android OS is simply just Google's flavor of
Linux.

And just look at how quickly the world has changed:

http://www.makeuseof.com/tag/infographic-internet-decade/
http://visual.ly/visual-guide-how-consumers-use-mobile-phones
http://visual.ly/social-media-social-good
http://visual.ly/mobile-trends-q4-2011-mobile-stats
http://visual.ly/generation-text

Of course, we must also be concerned with security/privacy issues:
http://visual.ly/what-our-phones-can-reveal-about-us

Also...   Guess what?

One can even access UseNet via their smartphone:
https://play.google.com/store/search?q=usenet&c=apps

I've seen plenty of 'netbook'-type computers being used.  Wouldn't be
surprised if they someday appear in a bubble-wrap at the checkout counter
for just a few dollars.

Nathan.

On 9/29/2012 11:16 PM, Nathan Baker wrote:

I have both a smartphone and a tablet, but that doesn't mean I have any
intention on giving up on PCs and laptops.

I actually most prefer using a desktop PC.

FWIW, the majority of netbooks are still x86-based...

however, they are unlikely to get *that* cheap, mostly as the cost of
materials and manufacture will probably set a lower bound.

I would estimate $50-$100 as probably a reasonable lower bound (in any
near-term sense).

maybe it could be a little cheaper (under $10) if the whole thing just
becomes a single larger SOC epoxied onto a plastic board with an OLED
display and essentially a rubber chicklet keyboard, and alkaline or NiCd
batteries, ...

another factor limiting the lower end is price-elasticity/plasticity:
if the cost goes down sufficiently low, most people wont really care how
much it costs anymore.

the difference between a $900 and $1100 laptop will matter a lot more
than the difference between $55 and $85 netbook, despite the latter
being a relatively larger difference.

or such...

Robert Wessel <robertwess...@yahoo.com> wrote in part:

Agreed.  Neither programmers nor hardware designers determine
"success" in our mercantile world -- customers do.

Small nit -- MIPs/W is not the important measure, ARM's success has
been based on low absolute power draw while performing "acceptably".
Intel x86 might be better MIPs/W but that is irrelevant since the
Watts are too high for mobile.

The collision will be interesting.  I have little doubt ARM
will achieve the required performance (full 1080p H.264 decode)
but some doubt x86 can be scaled that far back efficiently.  Yes,
Intel does have the best EE process around, but the Dell x86 tablets
underwhelm in spite of double thickness & weight.  I have no doubt
Intel is working on mobile, but they worked hard on the Itanium too.
Success is not guaranteed, nor can be forced, for technical developments.

S'phones/tablets have the potential to cannibalize one half the units
of the laptop/destop market.  Developing regions might skip to low-end
s'phones/tablets and use things like the RaspberryPi instead of x86.

The demise of "ugly" x86 has been long-predicted.  
ARM has that potential, but is even uglier.

-- Robert

news:k4ab57$8si$1@speranza.aioe.org...

I mentioned the same thing almost exactly two years ago.

Unfortunately, it was in an a.l.a. OT thread I initiated.  The alt.*
hierarchy has no topicality, but Redelmeier "plonked" me anyway.
So, I guess he didn't read it.

Why?

There is so much there they can remove.  It has multiple cpu modes, supports
multiple code sizes: 16-bit, 32-bit, 64-bit, has numerous uneeded features
like virtual memory, processor privilege levels, etc.  If x86 was reduced to
pure 32-bit or pure 64-bit without all the specialty features, then it
should be able compete.  If not, they can still design it to use fewer
transistors by not using standard logic blocks, i.e., hardcoded design.

Rod Pemberton

news:k48h3b$te0$1@speranza.aioe.org...

You're elected.

"Fup2" is not censored ... ?  Yes, I know you meant followup-to.

Hey, are you picking the name or are you going to let ... us ... vote on it?
:-)

E.g., comp.lang.asm.arm.

It'll get so many confusing comments about human arms and what they have to
do with assembly...  That's perfect.  A built in way to annoy newbs.  ;-)

New thread?

Oh, please don't me started on Big Brother.  Sadly, it's _everywhere_ now.
It's at truly scary levels of monitoring.

Rod Pemberton

news:k490jg$cnt$1@news.albasani.net...
...

To make it cheaper, more flexible, more customizable, I'd do something like
the following:

1) no supplied keyboard
2) no supplied screen
3) use the availability of standardized laptop components, like DVD-ROMs,
etc.
4) abuse the availability of USB devices - supply many USB ports for user
supplied keyboard, mouse, or other USB devices or adapters, etc.  The user
selects whether they want a $3 keyboard or a $120 keyboard.
5) SOC (system on a chip) - minus microprocessor, video, system memory.  The
goal here is to keep the system board the same except for the processor and
system memory.
6) accept older style memory that's still widely available, like DDR2.  The
system board will have to be updated periodically for market changes.
7) use an older style processor socket that's still has many processors
still available.  The system board will have to be updated periodically for
market changes.
8) install a smaller capacity SSD, e.g. 20GB, for better performance
9) design accepts wall power from standard laptop DC brick power supplies
10) design allows attachment of battery compartments of different sizes and
shapes and types of batteries
11) one battery compartment design should accept standard AA batteries.
This is so the user can use common rechargeables if they wish, instead of
expensive laptop batteries.
12) design allows permanent attachment of various sizes of screens or
touchscreens, or the user can connect to a monitor or computer goggles.  The
screens would be new aftermarket designs exclusively for this product.

Ok, some of those ideas may not be that great, but a few are good.  I can
see the heavy emphasis on USB devices as being similar to the annoying
numerous cable connected components of the old C64 computers.  The idea of
having motherboard design not change because of changes to the memory or
processor connectors is definately good.  Of course, that's not entirely
possible.  But, many changes can be minimized.

Rod Pemberton

On Mon, 1 Oct 2012 02:25:30 -0400, "Rod Pemberton"

Or the Mac Mini, which looks like a little hotplate studded
with ports.  (And it *does* get hot, since it has no fan.)

Best regards,

Bob Masta

              DAQARTA  v7.00
   Data AcQuisition And Real-Time Analysis
              www.daqarta.com
Scope, Spectrum, Spectrogram, Sound Level Meter
 Frequency Counter, Pitch Track, Pitch-to-MIDI
   FREE Signal Generator, DaqMusic generator    
          Science with your sound card!

On 10/1/2012 1:25 AM, Rod Pemberton wrote:

errm, a lot of this would actually make it more expensive...
the single big SOC epoxied onto a board is pretty cheap (this is the
type of construction popular in things like TV remotes and calculators).

traditionally, PCBs are made out of layered fiberglass, but potentially,
plastic-based boards could be cheaper, but would likely have issues with
the temperatures of soldering, meaning that no components could be
soldered onto such a board (a conductive epoxy or similar would be
needed instead of solder, which could cost more than the cost savings of
plastic vs fiberglass). other lower-cost PCBs use cotton-paper, which
has tradeoffs between those of plastic and fiberglass.

OLED has the potential of being somewhat cheaper than LCD, since
in-theory, they could be produced similar to that of printed materials
(you could have big rollers similar to those used for printing out
newspapers and magazines, but instead producing essentially reams of
cheap displays, likely printed on a plastic substrate...).

this would be in contrast to the more expensive practice of printing
traces onto glass and similar required for the construction of LCD
displays, and could also save on cost by not needing a backlight.

most likely, the SOC could be wired up to a SD-card or similar, which
would serve as the HDD (or use hard-mounted Flash chips).

11, pretty much matches what I was thinking, though probably people
would use AAA sized NiCd batteries. another reasonably cheap option
could be hard-mounting a bunch of NiCd button-cells.

although, looking into it, apparently NiMH batteries are cheaper at this
point than NiCd (LiON is still more expensive).

adding a port for removable batteries would likely add cost, so a
cheaper option would probably be to solder the batteries directly to the
MOBO.

so, likely, such a device would look like:
epoxy-mounted SOC, Flash chips, and batteries on one side;
metal contacts for keyboard keys on the other;
keyboard is basically just a later of rubber with contacts on the bottom
(when the rubber key is pushed down, it closes the circuit).

the display is directly connected to the MOBO, likely via a plastic-film
ribbon connector (similar to that of typical laptop displays).

internally, the thing would probably looks about like a TV-remote or
pocket calculator, but with a connected screen.

USB ports may or may not exist, but would likely be rarer, as USB ports
themselves cost money.

this would be for a "flexible" computer, but the topic was for a netbook
under $10.

modular design, however, would not save on manufacturing costs (rather,
it would make it more expensive).

cell-phones come close though, as I have seen cheap cell-phones for
around $25.

in these cases, typically the thing runs mostly on a big SOC, with the
RAM sort of stuck on top of the SOC (usually, the SOC will have a BGA
array on both the top and bottom, so that the SOC can sit there
sandwiched between the RAM and the board).

post-mount, it is common to put a big gob of epoxy around the whole
thing for sake of keeping the SOC firmly mounted onto the board
(otherwise, vibrations could break the BGA mounts and cause it to...
fall off...).

if a heat-sink is needed, it can also be placed on before the SOC is
epoxied, so externally it looks like a rounded black gob with some metal
fins sticking out.

or such...

On Sun, 30 Sep 2012 20:47:35 +0000 (UTC), Robert Redelmeier

That's not really true in the range where they're meeting (at least
for now). The low end Atoms are slower, but use more power, than the
high end ARMs.  The comparison is complicated by the fact that almost
all the ARMs are SOC-ish, while the Atoms are not, so exceptionally
poor chipset support for Atoms has had a much bigger negative impact
on Atom power consumption than anything comparable in the ARM world.
On the flip side, essentially all ARMs have significantly poorer
memory interfaces than x86s, which impacts their performance on memory
intensive workloads.

Higher up the scale, the MIPS/Watt of x86 generally falls off as
performance increases (the 100W server parts are not ten times faster
than the 10W laptop parts), but there's a substantial increase in
absolute performance.

But all three measures, power consumption, performance, and perf/watt
are important, although in varying degrees based on the application.

Rod Pemberton and others talked about...

from my point of view there is just a physical limit of either
speed performence or a cost/ability restruction or just a market
share goal, power consumtion vs. performance and some more ...

You'll never can satisfy more than two of all this various demands.

Sure AMD and Intel could give up on backwards compatible instruction-
support and as we already see this happend already with the transition
from 32 to 64-bit instruction encoding.

OTOH, me personally wouldn't have to much troubles if the former
octal register encoding became obsolete and might be substituted
by a more logical nibble addressing for 16 registers instead of
this REX/VEX workarounds in the opcodes itself ...

I can't see why we keep onto octal+Rex/Vex when we got a CPU which
got much more opportunities ... Perhaps just one more time a dictate
from Billy the Greedy and nothing else. I could live without M$-shit.
__
wolfgang (former hardware manufacturer 1979..1997)

news:k4cs5t$4i1$1@news.albasani.net...
...

It may make the total cost more expensive, but not necessarily.  The
manufacturer of such a device will only have a price discount on a
component, e.g., memory, if they buy large volumes.  If they can only
produce small quantities, then they can't get a discount.  Also,
competition for production of interchangeable or replaceable components
should help.

The PCB is one of the more expensive components in an electronic device. The
cheapest keyboard at my local computer store is $3.49 for PS/2 and $3.99 for
USB.  It's going to be difficult to undercut that price with a custom
circuit board for the keyboard.  It may undercut that price if a cheap "soft
rubber" keyboard is used, and a keyboard smaller in size than a PC keyboard
(less material).  However, it's still a custom part.  Custom parts cost more
than non-custom.  So, it will have some additional cost.  Whether it comes
out as less or more expensive overall is unknown at this point.

Besides the PCB, the display, transformer, or more expensive electronic
chips like a DSP, microprocessor, or memory are also expensive components.
That's why I suggested allowing the customer choose the display.  They can
buy a small, cheaper one, or larger, more expensive one, or connect to a
spare or donated monitor.

In the case of the SOC, the SOC itself and either microprocessor or memory
if needed, are expensive components.  An SOC without microprocessor becomes
a motherboard chipset.  "COTS" components (commercial off-the-shelf) are a
way to reduce cost.  E.g., a company I worked for reduced the cost of an
integrated bridge rectifier from around $1 USD to like 4/10,000ths of cent.
They bought rectifier diodes in bulk and used four of them.  Now, if you
know anything about reliability, then you know that four components are less
reliable than one.  But, the risk of reduced reliability was considered cost
justified.  I.e., it could be less expensive to use standard parts instead
of a custom SOC, e.g., an ARM with a FPGA, etc.

That same company I worked for used about four different types of PC boards.
One might've been fiberglass.  It broke the same way and had layers of
material, and fibers.  Another was a solid, but clear green, plastic like
material.  It didn't have layers.  It could soften like plastic when heated,
but also could shatter like glass (with alot of force applied).  The other
two appeared to be different types of cheap fiberboard.  I'm not sure of
their price, but those two were really "cheap" in terms of quality.  Just
soldering a component by hand would sometimes lift the trace wiring off of
the circuit board.  It was almost like the traces were cut or stamped and
glued on.  None of them had multi-layers, with wire traces in-between, like
modern x86 PC motherboards.  Their board wiring was all single-sided
(bottom) or double-sided (top and bottom).  A more expensive PCB cost as
much as the DSP we used in one product.

If it's too slow, a potential issue with SD, people will be underwhelmed.
Not being so slow requires more money.

I'd much rather have ports for a wired keyboard and mouse.  Of course, there
might be a standard wireless protocol(s) for wireless keyboard and mice.
Then, you could use any wireless keyboard or mouse with it.  At best,
standard PC components are COTS.

Under $10?  For a netbook?  You can't get a decent calculator for that.  How
are you going to get a decent netbook?  For a decent calculator, you're
looking at least $50 to $80, and closer to $100 to $150 (USD).  Assuming
wholesale is a 50% discount to retail, that's still $25 for a calculator,
not a netbook.  Using the "calculator model" of manufacturing, some company
probably could produce a netbook inexpensively, similar in appearance to a
Blackberry: chiclet keypad, small screen, custom chip.  Of course, then it
becomes a stripped-down smartphone with a faster processor...

I think a much better idea would be to have someone or a company subsidize
the price of a decent netbook.  A charity or non-profit corporation, a
wealthy benefactor or already existing charitable trust, a US government
grant, or some US government program for the needy, or a local business
grants, etc can help pay for the cost.  E.g., $90 from "primary" source
(charity) and $20 from "secondary" source (government program) and $10 from
the end-user, would allow for a $120 unit.  I think it's realistic if the
end-user is in the US, that they can pay much more than $10, say $100 or
$200, even if they're below US poverty thresholds.  Now, if the product is
for parts of Africa, I can understand the $10 goal, but it'd still be a
better outcome if it were subsidized.

It could raise the total cost, but not necessarily.  It depends on the
prices of components.  That's a function of volume and whether or not the
part is custom.  Calculators have long lifespans as compared to computers.
So, a custom chip is less expensive over the life of the product.  Standard
COTS components for PCs are pretty cheap.  They're high volume.  It's
possible a custom components will be more expensive than a COTS solution.
It's also possible the custom components could be less expensive, but that's
less likely, IMO.

...

read more »