So, who is going to buy the first Arm (M1) MacBooks? ;)
Thank you for reading and hopefully answering. :)
So, who is going to buy the first Arm (M1) MacBooks? ;)
In message <B5ednfUswZo00DHCnZ2dnUU7-LudnZ2d@earthlink.com> Ant <ant@zimage.comANT> wrote:
So, who is going to buy the first Arm (M1) MacBooks? ;)
I am ordering a MBA as soon as I decide if I should increase the RAM or
not. It will be mostly for my wife who almost certainly doesn't need
16GB, but I am torn.
On 2020-11-11 12:46 p.m., Ant wrote:
So, who is going to buy the first Arm (M1) MacBooks? ;)
Thank you for reading and hopefully answering. :)
I'm seriously considering it.
I'm about due for a new system...
...but I'm loath to be an earlier adopter.
:-)
In message <B5ednfUswZo00DHCnZ2dnUU7-LudnZ2d@earthlink.com> Ant <ant@zimage.comANT> wrote:
So, who is going to buy the first Arm (M1) MacBooks? ;)
I am ordering a MBA as soon as I decide if I should increase the RAM or
not. It will be mostly for my wife who almost certainly doesn't need
16GB, but I am torn.
It looks like Apple doesn't even sell its old Intel Macs from its web site? :(
It looks like Apple doesn't even sell its old Intel Macs from its web site? :(
Aren't the RAMs still soldered in? If so, then you might as well go as big as
you can afford. Same for storage. :(
In comp.sys.mac.system Lewis <g.kreme@kreme.dont-email.me> wrote:
In message <B5ednfUswZo00DHCnZ2dnUU7-LudnZ2d@earthlink.com> Ant <ant@zimage.comANT> wrote:
So, who is going to buy the first Arm (M1) MacBooks? ;)
I am ordering a MBA as soon as I decide if I should increase the RAM or
not. It will be mostly for my wife who almost certainly doesn't need
16GB, but I am torn.
Aren't the RAMs still soldered in? If so, then you might as well go as big as
you can afford. Same for storage. :(
In comp.sys.mac.system Alan Baker <notonyourlife@no.no.no.no> wrote:
On 2020-11-11 12:46 p.m., Ant wrote:
So, who is going to buy the first Arm (M1) MacBooks? ;)
Thank you for reading and hopefully answering. :)
I'm seriously considering it.
I'm about due for a new system...
...but I'm loath to be an earlier adopter.
:-)
It looks like Apple doesn't even sell its old Intel Macs from its web site? :(
In comp.sys.mac.system Lewis <g.kreme@kreme.dont-email.me> wrote:
In message <B5ednfUswZo00DHCnZ2dnUU7-LudnZ2d@earthlink.com> Ant
<ant@zimage.comANT> wrote:
So, who is going to buy the first Arm (M1) MacBooks? ;)
I am ordering a MBA as soon as I decide if I should increase the RAM or
not. It will be mostly for my wife who almost certainly doesn't need
16GB, but I am torn.
Aren't the RAMs still soldered in? If so, then you might as well go as big as you can afford. Same for storage. :(
On 2020-11-11 2:40 p.m., Ant wrote:
In comp.sys.mac.system Alan Baker <notonyourlife@no.no.no.no> wrote:
On 2020-11-11 12:46 p.m., Ant wrote:
So, who is going to buy the first Arm (M1) MacBooks? ;)
Thank you for reading and hopefully answering. :)
I'm seriously considering it.
I'm about due for a new system...
...but I'm loath to be an earlier adopter.
:-)
It looks like Apple doesn't even sell its old Intel Macs from its web site? :(
Nope.
It doesn't look like that at all.
PEBCAK
It looks like Apple doesn't even sell its old Intel Macs from its web site? :(
The 16GB config max for the Air is laughable.
On 11 Nov 2020 at 22:40:09 GMT, Ant <Ant> wrote:
It looks like Apple doesn't even sell its old Intel Macs from its web site? :(
You can still buy Intel Minis.
On 2020-11-11 22:40:49 +0000, Ant said:
In comp.sys.mac.system Lewis <g.kreme@kreme.dont-email.me> wrote:
In message <B5ednfUswZo00DHCnZ2dnUU7-LudnZ2d@earthlink.com> Ant
<ant@zimage.comANT> wrote:
So, who is going to buy the first Arm (M1) MacBooks? ;)
I am ordering a MBA as soon as I decide if I should increase the RAM or
not. It will be mostly for my wife who almost certainly doesn't need
16GB, but I am torn.
Aren't the RAMs still soldered in? If so, then you might as well go as big as
you can afford. Same for storage. :(
Yep. It is one of the biggest pain-in-the-backside points with Apple
these days, especially considering Apple's over-pricing of RAM and
storage drives. :-(
It looks like Apple doesn't even sell its old Intel Macs from its web site? :(
You can still buy Intel Minis.
Ah, but no MacBooks?
In comp.sys.mac.hardware.misc Tim <timstreater@greenbee.net> wrote:
On 11 Nov 2020 at 22:40:09 GMT, Ant <Ant> wrote:
It looks like Apple doesn't even sell its old Intel Macs from its web site? :(
You can still buy Intel Minis.
Ah, but no MacBooks?
On 2020-11-11 2:22 p.m., Lewis wrote:
In message <B5ednfUswZo00DHCnZ2dnUU7-LudnZ2d@earthlink.com> Ant <ant@zimage.comANT> wrote:
So, who is going to buy the first Arm (M1) MacBooks? ;)
I am ordering a MBA as soon as I decide if I should increase the RAM or
not. It will be mostly for my wife who almost certainly doesn't need
16GB, but I am torn.
Spend the money and get the 16GB.
You're buying a machine to last the next 5 years or more. The extra RAM
will cost you (I'm in Canada) about $250CAD, so that's $50 per year to ensure the machine has what it will need for the latter part of its life.
In comp.sys.mac.system Lewis <g.kreme@kreme.dont-email.me> wrote:
In message <B5ednfUswZo00DHCnZ2dnUU7-LudnZ2d@earthlink.com> Ant <ant@zimage.comANT> wrote:
So, who is going to buy the first Arm (M1) MacBooks? ;)
I am ordering a MBA as soon as I decide if I should increase the RAM or
not. It will be mostly for my wife who almost certainly doesn't need
16GB, but I am torn.
Aren't the RAMs still soldered in? If so, then you might as well go as big as
you can afford. Same for storage. :(
In comp.sys.mac.hardware.misc Your Name <YourName@yourisp.com> wrote:
On 2020-11-11 22:40:49 +0000, Ant said:
In comp.sys.mac.system Lewis <g.kreme@kreme.dont-email.me> wrote:
In message <B5ednfUswZo00DHCnZ2dnUU7-LudnZ2d@earthlink.com> Ant
<ant@zimage.comANT> wrote:
So, who is going to buy the first Arm (M1) MacBooks? ;)
I am ordering a MBA as soon as I decide if I should increase the RAM or >> >> not. It will be mostly for my wife who almost certainly doesn't need
16GB, but I am torn.
Aren't the RAMs still soldered in? If so, then you might as well go as big as
you can afford. Same for storage. :(
Yep. It is one of the biggest pain-in-the-backside points with Apple
these days, especially considering Apple's over-pricing of RAM and
storage drives. :-(
That's frustrating. :(
It looks like Apple doesn't even sell its old Intel Macs from its web site? :(
The 16GB config max for the Air is laughable. Consider how much focus
on graphic designers/video editors there was in the keynote.
In article <VU%qH.433945$r25.305379@fx08.iad>, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
The 16GB config max for the Air is laughable.
it's a completely different architecture, therefore direct comparisons
are bogus.
ipads and iphones do exceptionally well with 4 gig.
In article <VU%qH.433945$r25.305379@fx08.iad>, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
The 16GB config max for the Air is laughable.
it's a completely different architecture, therefore direct comparisons
are bogus.
ipads and iphones do exceptionally well with 4 gig.
No it's not. It means the RAM is much faster and more tightly integrated
with the CPU and GPU and that much less needs to be moved around (for
one, no copying RAM from the "system" to the "GPU".
Going from CISC 32 bit VAX
To say that moving from 8086 to ARM will require less memory is not logica.
Another aspect: that 8 or 16GB on a M1 based MAC is used for both the
CPU and the GPUs. So less of the RAM is actually available to the OS
because the GPUs use the same RAM.
Asll we know is "unified memory" which is meaningless marketing mumble jumble.
one major advantage is both the cpu and gpu can access the same data, eliminating the need to copy it. another advantage is that the memory
itself is much faster.
What sort of memery controller Apple uses will matter, especially when
Asll we know is "unified memory" which is meaningless marketing mumble jumble.
It is only once independant testers riun standard benchmarks that we'll
have an idea of actual performance. Apple's keynote provided nothing of
value on performance. (look at their graphs, pretty lines, but no scale/numbers for each axis).
Consider also that the Pro has a fan, the air doesn't. Yet, same CPU,
same OS. So it is very likely that the Air will be speed throttled due
to heat
while the Pro will see better performance when doing lengthy work.
And it will make for interesting benchmark logic because you have cores
of different speeds.
The 4 slow cores will slow down the average of the 4 fast ones.
On 2020-11-11 20:15, nospam wrote:
In article <VU%qH.433945$r25.305379@fx08.iad>, JF Mezei
<jfmezei.spamnot@vaxination.ca> wrote:
The 16GB config max for the Air is laughable.
it's a completely different architecture, therefore direct comparisons
are bogus.
ipads and iphones do exceptionally well with 4 gig.
In the keynote, Apple bragged about 8k video rendering on the MacBook Air.
ARM being RISC, it should in fact require more instructions to do the
same work as CISC 8086.
Going from CISC 32 bit VAX
one major advantage is both the cpu and gpu can access the same data, eliminating the need to copy it. another advantage is that the memory itself is much faster.
Yes, you save when the app transfers to the GPU the scene description.
scene. But the GPU also uses a lot of memory to render the scene for
each frame. And that is a lot of memory used by the GPU which now draws
from RAM available to the CPU.
In article <ImqrH.448051$I15.366080@fx36.iad>, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
one major advantage is both the cpu and gpu can access the same data,
eliminating the need to copy it. another advantage is that the memory
itself is much faster.
Yes, you save when the app transfers to the GPU the scene description.
scene. But the GPU also uses a lot of memory to render the scene for
each frame. And that is a lot of memory used by the GPU which now draws
from RAM available to the CPU.
you don't understand how things work, do you?
In article <VU%qH.433945$r25.305379@fx08.iad>, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
The 16GB config max for the Air is laughable.
it's a completely different architecture, therefore direct comparisons
are bogus.
ipads and iphones do exceptionally well with 4 gig.
In message <131120200630461436%nospam@nospam.invalid> nospam <nospam@nospam.invalid> wrote:
In article <ImqrH.448051$I15.366080@fx36.iad>, JF Mezei
<jfmezei.spamnot@vaxination.ca> wrote:
one major advantage is both the cpu and gpu can access the same
data, eliminating the need to copy it. another advantage is that
the memory itself is much faster.
Yes, you save when the app transfers to the GPU the scene
description. scene. But the GPU also uses a lot of memory to render
the scene for each frame. And that is a lot of memory used by the
GPU which now draws from RAM available to the CPU.
you don't understand how things work, do you?
He really doesn't. At all.
ARM being RISC,
On 2020-11-11 20:15, nospam wrote:
In article <VU%qH.433945$r25.305379@fx08.iad>, JF Mezei
<jfmezei.spamnot@vaxination.ca> wrote:
The 16GB config max for the Air is laughable.
it's a completely different architecture, therefore direct comparisons
are bogus.
ipads and iphones do exceptionally well with 4 gig.
Another aspect: that 8 or 16GB on a M1 based MAC is used for both the
CPU and the GPUs.
In article <uOfrH.514768$RY8.72367@fx48.iad>, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
Asll we know is "unified memory" which is meaningless marketing mumble
jumble.
nonsense.
On 2020-11-12 13:34, JF Mezei wrote:CISCier... I meant to say.
ARM being RISC,
ARM's are RISCier than ever before just as CISC's are RISCier than ever.
Why that distinction is not talked about anymore ... or for that matter
over the last 10 years or so for most computers. It does still matter
in lower end devices (routers for example) v. intel based microcontrollers.
Further, it's likely that Apple are implementing their own specialized instructions which would be CISCy, not RISCy.
you don't understand how things work, do you?
He really doesn't. At all.
Further, it's likely that Apple are implementing their own specialized instructions which would be CISCy, not RISCy.
On 2020-11-13 10:43, Lewis wrote:
you don't understand how things work, do you?
He really doesn't. At all.
Perhaps you could do the community a favour and explain how PCI-E GPUs
work and how the Apple ones which share RAM will work.
On 2020-11-13 10:43, Lewis wrote:
you don't understand how things work, do you?
He really doesn't. At all.
Perhaps you could do the community a favour and explain how PCI-E GPUs
work and how the Apple ones which share RAM will work.
On 2020-11-12 14:21, nospam wrote:
In article <uOfrH.514768$RY8.72367@fx48.iad>, JF Mezei
<jfmezei.spamnot@vaxination.ca> wrote:
Asll we know is "unified memory" which is meaningless marketing mumble
jumble.
nonsense.
It is marketing speak to a degree. Per a Wikipedia article[1] the SOC
uses 3733 MHz LPDDR4X spec'd SDRAM as an included component within the
SOC. Still needs a memory manager though that may be more deeply
integrated in the CPU; likely has DMA of some kind, esp. for the GPU,
but other I/O as well.
[1] that source has no reference so I declare escape clause. But it's a good bet if someone has seen that in System Info declared as such on the many, many developer systems out there.
On 2020-11-13 11:43, Alan Browne wrote:
Further, it's likely that Apple are implementing their own specialized
instructions which would be CISCy, not RISCy.
Apple seems to ave focued on adding discrete components such as the
neural processor, image processor etc to do these tasks. Adding
instructions would require compilers and LLVM be updated and be
specific to Apple and it is doubtful rhere would be much use of them.
Please remembes that the apologists argued that an ARM binary would be smaller than an Intel one , hence need for less RAM on the laptop. That
is what I was responding to.
In message <0VyrH.145047$Ml5.103301@fx24.iad> Alan Browne <bitbucket@blackhole.com> wrote:
On 2020-11-12 14:21, nospam wrote:
In article <uOfrH.514768$RY8.72367@fx48.iad>, JF Mezei
<jfmezei.spamnot@vaxination.ca> wrote:
Asll we know is "unified memory" which is meaningless marketing mumble >>>> jumble.
nonsense.
It is marketing speak to a degree. Per a Wikipedia article[1] the SOC
uses 3733 MHz LPDDR4X spec'd SDRAM as an included component within the
SOC. Still needs a memory manager though that may be more deeply
integrated in the CPU; likely has DMA of some kind, esp. for the GPU,
but other I/O as well.
[1] that source has no reference so I declare escape clause. But it's a
good bet if someone has seen that in System Info declared as such on the
many, many developer systems out there.
What many many developer systems out there?
(The DTK is not an M1 machine).
Perhaps you should do your own research as you have proved countless
times that you are incapable of learning from anything posted here.
On 2020-11-13 15:18, Lewis wrote:
Perhaps you should do your own research as you have proved countless
times that you are incapable of learning from anything posted here.
So you insult
On 2020-11-13 15:20, Lewis wrote:
In message <0VyrH.145047$Ml5.103301@fx24.iad> Alan Browne <bitbucket@blackhole.com> wrote:
On 2020-11-12 14:21, nospam wrote:
In article <uOfrH.514768$RY8.72367@fx48.iad>, JF Mezei
<jfmezei.spamnot@vaxination.ca> wrote:
Asll we know is "unified memory" which is meaningless marketing mumble >>>>> jumble.
nonsense.
It is marketing speak to a degree. Per a Wikipedia article[1] the SOC
uses 3733 MHz LPDDR4X spec'd SDRAM as an included component within the
SOC. Still needs a memory manager though that may be more deeply
integrated in the CPU; likely has DMA of some kind, esp. for the GPU,
but other I/O as well.
[1] that source has no reference so I declare escape clause. But it's a >>> good bet if someone has seen that in System Info declared as such on the >>> many, many developer systems out there.
What many many developer systems out there?
Thousands...
(The DTK is not an M1 machine).
I assumed it was.
Nevertheless, the use of the memory model cited above is quite
possible and that that part of the fab is supplied by the chip maker
whether on the same wafer or other.
And/or that someone made the same assumption that I did about the memory found on the dev kit.
(The DTK is not an M1 machine).
I assumed it was.
You assumed wrong. As was detailed at the time it is a A12X. Literally
an iPad chip. It does not have unified memory. It does not have
USB-4/TB. It is not the same chip *at all*
In article <slrnrquali.1fdt.g.kreme@ProMini.lan>, Lewis <g.kreme@kreme.dont-email.me> wrote:
(The DTK is not an M1 machine).
I assumed it was.
You assumed wrong. As was detailed at the time it is a A12X. Literally
an iPad chip. It does not have unified memory. It does not have
USB-4/TB. It is not the same chip *at all*
actually, it was an a12z.
it was basically an ipad in a mac mini box.
which is good enough for development work.
Yeo, especially considering how simple the transition from Intel to ARM
was for the developers (One spent several days porting, but the others
did their ports in under a day and one spent less than 15 minutes).
Yeo, especially considering how simple the transition from Intel to ARM
was for the developers (One spent several days porting, but the others
did their ports in under a day and one spent less than 15 minutes).
Simple enough that it will take months more for Adobe to release native Photoshop.
If you want to create binaries that make use of the new various sub-processors like neural engine, image processor etc, support the integrated GPUs etc, you need to start putting in a lot of conditional
code that applies only for a compilation targetted at the Mx chips, and
still generate your normal code for all other platforms.
Remains to be seen how much use Adobe will make the the proprietary processors around he CPU, and how much Metal/GPU they will use.
It is also possible that merely recompiling wouldn't have yielded
marketable performance.
It is also possible that Adobe is waiting for usable Macs (aka: next
models with more RAM) and the delay has nothing to do with the porting effort.
On 2020-11-14 04:47, Lewis wrote:
Yeo, especially considering how simple the transition from Intel to ARM
was for the developers (One spent several days porting, but the others
did their ports in under a day and one spent less than 15 minutes).
Simple enough that it will take months more for Adobe to release native Photoshop.
If you want to create binaries that make use of the new various sub-processors like neural engine, image processor etc, support the integrated GPUs etc, you need to start putting in a lot of conditional
code that applies only for a compilation targetted at the Mx chips, and
still generate your normal code for all other platforms.
Remains to be seen how much use Adobe will make the the proprietary processors around he CPU, and how much Metal/GPU they will use.
In message <HhCrH.320247$GQ4.306084@fx02.iad> Alan Browne <bitbucket@blackhole.com> wrote:
On 2020-11-13 15:20, Lewis wrote:
In message <0VyrH.145047$Ml5.103301@fx24.iad> Alan Browne <bitbucket@blackhole.com> wrote:
On 2020-11-12 14:21, nospam wrote:
In article <uOfrH.514768$RY8.72367@fx48.iad>, JF Mezei
<jfmezei.spamnot@vaxination.ca> wrote:
Asll we know is "unified memory" which is meaningless marketing mumble >>>>>> jumble.
nonsense.
It is marketing speak to a degree. Per a Wikipedia article[1] the SOC >>>> uses 3733 MHz LPDDR4X spec'd SDRAM as an included component within the >>>> SOC. Still needs a memory manager though that may be more deeply
integrated in the CPU; likely has DMA of some kind, esp. for the GPU,
but other I/O as well.
[1] that source has no reference so I declare escape clause. But it's a >>>> good bet if someone has seen that in System Info declared as such on the >>>> many, many developer systems out there.
What many many developer systems out there?
Thousands...
Nonsense.
(The DTK is not an M1 machine).
I assumed it was.
You assumed wrong. As was detailed at the time it is a A12X. Literally
an iPad chip. It does not have unified memory. It does not have
USB-4/TB. It is not the same chip *at all*
Nevertheless, the use of the memory model cited above is quite
possible and that that part of the fab is supplied by the chip maker
whether on the same wafer or other.
The chip maker supplies exactly what Apple designed, nothing more,
nothing less.
On 2020-11-14 04:47, Lewis wrote:
Yeo, especially considering how simple the transition from Intel to
ARM was for the developers (One spent several days porting, but the
others did their ports in under a day and one spent less than 15
minutes).
Simple enough that it will take months more for Adobe to release
native Photoshop.
On 2020-11-13 19:54, Lewis wrote:
In message <HhCrH.320247$GQ4.306084@fx02.iad> Alan Browne <bitbucket@blackhole.com> wrote:
On 2020-11-13 15:20, Lewis wrote:
In message <0VyrH.145047$Ml5.103301@fx24.iad> Alan Browne <bitbucket@blackhole.com> wrote:
On 2020-11-12 14:21, nospam wrote:
In article <uOfrH.514768$RY8.72367@fx48.iad>, JF Mezei
<jfmezei.spamnot@vaxination.ca> wrote:
Asll we know is "unified memory" which is meaningless marketing mumble >>>>>>> jumble.
nonsense.
It is marketing speak to a degree. Per a Wikipedia article[1] the SOC >>>>> uses 3733 MHz LPDDR4X spec'd SDRAM as an included component within the >>>>> SOC. Still needs a memory manager though that may be more deeply
integrated in the CPU; likely has DMA of some kind, esp. for the GPU, >>>>> but other I/O as well.
[1] that source has no reference so I declare escape clause. But it's a >>>>> good bet if someone has seen that in System Info declared as such on the >>>>> many, many developer systems out there.
What many many developer systems out there?
Thousands...
Nonsense.
Really. Even my lowly Pascal compiler developer got one and very
quickly. It was underwhelming in the sense that the new compiler was
tested and ready in mere days.
Simplest path: spec an existing type that is in the fabs capability and meets the spec.
I miss the old days. I haven't killed anyone in years.
In message <aSRrH.889498$AN2.12718@fx46.iad> Alan Browne <bitbucket@blackhole.com> wrote:
On 2020-11-13 19:54, Lewis wrote:
In message <HhCrH.320247$GQ4.306084@fx02.iad> Alan Browne <bitbucket@blackhole.com> wrote:
On 2020-11-13 15:20, Lewis wrote:
In message <0VyrH.145047$Ml5.103301@fx24.iad> Alan Browne <bitbucket@blackhole.com> wrote:
On 2020-11-12 14:21, nospam wrote:
In article <uOfrH.514768$RY8.72367@fx48.iad>, JF Mezei
<jfmezei.spamnot@vaxination.ca> wrote:
Asll we know is "unified memory" which is meaningless marketing mumble >>>>>>>> jumble.
nonsense.
It is marketing speak to a degree. Per a Wikipedia article[1] the SOC >>>>>> uses 3733 MHz LPDDR4X spec'd SDRAM as an included component within the >>>>>> SOC. Still needs a memory manager though that may be more deeply
integrated in the CPU; likely has DMA of some kind, esp. for the GPU, >>>>>> but other I/O as well.
[1] that source has no reference so I declare escape clause. But it's a >>>>>> good bet if someone has seen that in System Info declared as such on the >>>>>> many, many developer systems out there.
What many many developer systems out there?
Thousands...
Nonsense. [1] <------
Really. Even my lowly Pascal compiler developer got one and very
quickly. It was underwhelming in the sense that the new compiler was
tested and ready in mere days.
Again, the DTK Is NOT the M1 mac. At all.
Simplest path: spec an existing type that is in the fabs capability and
meets the spec.
Are you channeling JF?
photoshop is a very complex app, with some core routines in assembly
that are hand tuned to specific versions of processors.
given that portions of photoshop are x86 assembly, it would be
impossible to 'merely recompile' it.
given that portions of photoshop are x86 assembly, it would be
impossible to 'merely recompile' it.
Fuck off, FUDster. Adobe is famous in the Mac community for taking
longer than most other developers to update their apps.
On 2020-11-14 10:41, Jolly Roger wrote:
Fuck off, FUDster. Adobe is famous in the Mac community for taking
longer than most other developers to update their apps.
Are you calling Tim Cook a FUDster? he is the one who announced
Photoshop would arrive next year.
given that portions of photoshop are x86 assembly, it would be
impossible to 'merely recompile' it.
Surprised at that allegation since Photoshop used to run on 68k, PowerPC
and 32 bit 8086s.
The GPUs take in C++ code (or variant thereof). And x86 code isn't
optimized, so generally only used for low level hardware interfaces.
It wasn't that long ago that you and your ilk even refised to admit that
OS-X would have any assembly language, and now you state Photoshop (a
user mode application) has assembler.
Depending on demand, there might be an x26 assembler *compiler* which
would then generate optimised ARM opcodes.
When Digital did the migration from VAX to Alpha,
photoshop is a very complex app, with some core routines in assembly
that are hand tuned to specific versions of processors.
given that portions of photoshop are x86 assembly, it would be
impossible to 'merely recompile' it.
Such can be done with translation tools (_x86 -> ARM assembler).
They've possibly developed or acquired such for their iOS products.
On 2020-11-14 08:29, nospam wrote:
given that portions of photoshop are x86 assembly, it would be
impossible to 'merely recompile' it.
Surprised at that allegation since Photoshop used to run on 68k, PowerPC
and 32 bit 8086s.
The GPUs take in C++ code (or variant thereof). And x86 code isn't
optimized, so generally only used for low level hardware interfaces.
It wasn't that long ago that you and your ilk even refised to admit that
OS-X would have any assembly language, and now you state Photoshop (a
user mode application) has assembler.
Depending on demand, there might be an x26 assembler *compiler* which
would then generate optimised ARM opcodes.
When Digital did the migration from VAX to Alpha,
However, I suspect the amount of x86 assembler in the OS-X ecosystem is really not sufficient to warrant developing such a compiler. The
assembler portions in OS-X would be very low level and hace to be
rewritten to the new ARM environment (device interfaces etc) so a
compiler not very useful.
On 2020-11-14 11:51, Lewis wrote:
In message <aSRrH.889498$AN2.12718@fx46.iad> Alan Browne <bitbucket@blackhole.com> wrote:
On 2020-11-13 19:54, Lewis wrote:
In message <HhCrH.320247$GQ4.306084@fx02.iad> Alan Browne <bitbucket@blackhole.com> wrote:
On 2020-11-13 15:20, Lewis wrote:
In message <0VyrH.145047$Ml5.103301@fx24.iad> Alan Browne <bitbucket@blackhole.com> wrote:
On 2020-11-12 14:21, nospam wrote:
In article <uOfrH.514768$RY8.72367@fx48.iad>, JF Mezei
<jfmezei.spamnot@vaxination.ca> wrote:
Asll we know is "unified memory" which is meaningless marketing mumble
jumble.
nonsense.
It is marketing speak to a degree. Per a Wikipedia article[1] the SOC >>>>>>> uses 3733 MHz LPDDR4X spec'd SDRAM as an included component within the >>>>>>> SOC. Still needs a memory manager though that may be more deeply >>>>>>> integrated in the CPU; likely has DMA of some kind, esp. for the GPU, >>>>>>> but other I/O as well.
[1] that source has no reference so I declare escape clause. But it's a
good bet if someone has seen that in System Info declared as such on the
many, many developer systems out there.
What many many developer systems out there?
Thousands...
Nonsense. [1] <------
Really. Even my lowly Pascal compiler developer got one and very
quickly. It was underwhelming in the sense that the new compiler was
tested and ready in mere days.
Again, the DTK Is NOT the M1 mac. At all.
Yeah, resolved in prior posts.
I wasn't being specific to the processor - only that Apple put out
thousands of transition developer kits.
Simplest path: spec an existing type that is in the fabs capability and
meets the spec.
Are you channeling JF?
Not at all.
On 2020-11-14 08:29, nospam wrote:
given that portions of photoshop are x86 assembly, it would be
impossible to 'merely recompile' it.
Surprised at that allegation since Photoshop used to run on 68k, PowerPC
and 32 bit 8086s.
The GPUs take in C++ code (or variant thereof). And x86 code isn't
optimized, so generally only used for low level hardware interfaces.
It wasn't that long ago that you and your ilk even refised to admit that
OS-X would have any assembly language,
When Digital did the migration from VAX
In article <WmUrH.138317$nI.132802@fx21.iad>, Alan Browne <bitbucket@blackhole.com> wrote:
photoshop is a very complex app, with some core routines in assembly<s>
that are hand tuned to specific versions of processors.
given that portions of photoshop are x86 assembly, it would be
impossible to 'merely recompile' it.
Such can be done with translation tools (_x86 -> ARM assembler).
They've possibly developed or acquired such for their iOS products.
it can, but it would not be anywhere close to optimal.
given that portions of photoshop are x86 assembly, it would be
impossible to 'merely recompile' it.
Surprised at that allegation since Photoshop used to run on 68k, PowerPC and 32 bit 8086s.
An you think they simply recompiled the 68000 code for Intel Are ou
really that daft?
In message <ceUrH.308904$1a1.122503@fx18.iad> Alan Browne <bitbucket@blackhole.com> wrote:
On 2020-11-14 11:51, Lewis wrote:
In message <aSRrH.889498$AN2.12718@fx46.iad> Alan Browne <bitbucket@blackhole.com> wrote:
On 2020-11-13 19:54, Lewis wrote:
In message <HhCrH.320247$GQ4.306084@fx02.iad> Alan Browne <bitbucket@blackhole.com> wrote:
On 2020-11-13 15:20, Lewis wrote:
In message <0VyrH.145047$Ml5.103301@fx24.iad> Alan Browne <bitbucket@blackhole.com> wrote:
On 2020-11-12 14:21, nospam wrote:
In article <uOfrH.514768$RY8.72367@fx48.iad>, JF Mezei
<jfmezei.spamnot@vaxination.ca> wrote:
Asll we know is "unified memory" which is meaningless marketing mumble
jumble.
nonsense.
It is marketing speak to a degree. Per a Wikipedia article[1] the SOC >>>>>>>> uses 3733 MHz LPDDR4X spec'd SDRAM as an included component within the >>>>>>>> SOC. Still needs a memory manager though that may be more deeply >>>>>>>> integrated in the CPU; likely has DMA of some kind, esp. for the GPU, >>>>>>>> but other I/O as well.
[1] that source has no reference so I declare escape clause. But it's a
good bet if someone has seen that in System Info declared as such on the
many, many developer systems out there.
What many many developer systems out there?
Thousands...
Nonsense. [1] <------
Really. Even my lowly Pascal compiler developer got one and very
quickly. It was underwhelming in the sense that the new compiler was
tested and ready in mere days.
Again, the DTK Is NOT the M1 mac. At all.
Yeah, resolved in prior posts.
I wasn't being specific to the processor - only that Apple put out
thousands of transition developer kits.
You were talking out the unified memory in the M1 chip and comparing it
to the DTK.
Simplest path: spec an existing type that is in the fabs capability and >>>> meets the spec.
Are you channeling JF?
Not at all.
Seems like it. The M1 is not an "existing type" it is a new chip
designed by Apple and made to their design. it is not being assembled out
of other bits.
Not at all. In treating large sets of integer values (which is what a digital image is "made of"), assembler offers many ways to do many
things very efficiently and further allows for the ultimate of
optimization and clever tricks that are not expressable efficiently in
high level language.
x26 assembler? Eh? *compiler*? Do you mean translator or converter?
Sure. Quite plausible.
... get over it already.
You mean translator.
The ARM assembler is available and Apple expressly provide their
guidelines to developers for using ARM assembly language
An you think they simply recompiled the 68000 code for Intel Are ou
really that daft?
do you really need to ask?
And Assembler, by definition, generates opcodes that match your code
both in nature and order. No optimizatiosn possible.
However, when a chip has an instruction to decode an H.264 stream for instance, it can be more efficient to use assembler to use that
instriuction vs writing your own in higher level language that gets optimized.
This is why Digital did a compiler for its Macro assembler when moving platform so that the CISC VAX
Argument was made that Adobe had to rewrite large parts because they
were in 8086 assembly.
I counterred that Adobe already had multi platfor
support in the past. So they can rewrite parts for ARM if they want to.
But it does show that it isn't just a simple recompile.
On 2020-11-14 13:26, Alan Browne wrote:
Not at all. In treating large sets of integer values (which is what a
digital image is "made of"), assembler offers many ways to do many
things very efficiently and further allows for the ultimate of
optimization and clever tricks that are not expressable efficiently in
high level language.
When moving to RISC, this changes the equation because of the large
number of optomizations possible buy re-ordering of opcodes to allow the
chip to make best use of pipeline, branch prediction and other
perofrmance techniques.
And Assembler, by definition, generates opcodes that match your code
both in nature and order. No optimizatiosn possible.
However, when a chip has an instruction to decode an H.264 stream for instance, it can be more efficient to use assembler to use that
instriuction vs writing your own in higher level language that gets optimized.
x26 assembler? Eh? *compiler*? Do you mean translator or converter?
Sure. Quite plausible.
COMPILER. The compiler treats the source as high level language and
does the optimization, re-ordering of the code to fit the target archictecture. A translator merely translates already compiled code
without trying to understand the code and optmize it.
Rosetta 2 is a translator that takes code optimized for 8086 and
translates it to multiple ARM instructions that do the same whereas recompiling will optimise the binary to run on ARM.
This is why Digital died.
... get over it already.
So you refuse to discuss experiences of other ports and wish to keep
your head in sand and and blindly drink Apple's kool aid.
You mean translator.
For applicationn where performance counts, I mean COMPILER. Where low
level code is truly needed, assembler is used because you can't optimize
it and it needs to be rewritten from scratch because handling of device drivers, the types of io interfaces etc all very different.
In the case of OS-X, much already exists from IOS, so much could be
re-used, but there is still code needed for the new thunderbolt/USB-4
drivers and all the variants attached to it, including ethernet drivers attached to the new thunderbolt/USB-4 IO interface.
The ARM assembler is available and Apple expressly provide their
guidelines to developers for using ARM assembly language
I am sure it is. But when targetting a RISC platform, assembly language
is much harder to beat efficieny of higher level languages because of compiler and LLVM optimizations which know about how that CPU does instruction pre-fetching, pipelining, branch prediction, etc.
On 2020-11-14 13:34, Lewis wrote:
In message <ceUrH.308904$1a1.122503@fx18.iad> Alan Browne <bitbucket@blackhole.com> wrote:
On 2020-11-14 11:51, Lewis wrote:
In message <aSRrH.889498$AN2.12718@fx46.iad> Alan Browne <bitbucket@blackhole.com> wrote:
On 2020-11-13 19:54, Lewis wrote:
In message <HhCrH.320247$GQ4.306084@fx02.iad> Alan Browne <bitbucket@blackhole.com> wrote:
On 2020-11-13 15:20, Lewis wrote:
In message <0VyrH.145047$Ml5.103301@fx24.iad> Alan Browne <bitbucket@blackhole.com> wrote:
On 2020-11-12 14:21, nospam wrote:
In article <uOfrH.514768$RY8.72367@fx48.iad>, JF Mezei
<jfmezei.spamnot@vaxination.ca> wrote:
Asll we know is "unified memory" which is meaningless marketing mumble
jumble.
nonsense.
It is marketing speak to a degree. Per a Wikipedia article[1] the SOC
uses 3733 MHz LPDDR4X spec'd SDRAM as an included component within the
SOC. Still needs a memory manager though that may be more deeply >>>>>>>>> integrated in the CPU; likely has DMA of some kind, esp. for the GPU, >>>>>>>>> but other I/O as well.
[1] that source has no reference so I declare escape clause. But it's a
good bet if someone has seen that in System Info declared as such on the
many, many developer systems out there.
What many many developer systems out there?
Thousands...
Nonsense. [1] <------
Really. Even my lowly Pascal compiler developer got one and very
quickly. It was underwhelming in the sense that the new compiler was >>>>> tested and ready in mere days.
Again, the DTK Is NOT the M1 mac. At all.
Yeah, resolved in prior posts.
I wasn't being specific to the processor - only that Apple put out
thousands of transition developer kits.
You were talking out the unified memory in the M1 chip and comparing it
to the DTK.
I took your objection to be the word "Thousands". That was me
referencing the number of dev kits. Not what specific processor was in there.
Simplest path: spec an existing type that is in the fabs capability and >>>>> meets the spec.
Are you channeling JF?
Not at all.
Seems like it. The M1 is not an "existing type" it is a new chip
designed by Apple and made to their design. it is not being assembled out
of other bits.
Those elements can come from different designers(companies) with the
data for the design transferred to Apple to integrate into their overall design by specification.
Apple claim "16 billion transistors" for the M1. That can't possibly represent the entire CPU + 8 GB or 16 GB of memory. (8 GiB would take a minimum of 64B transistors for a DRAM and 6 times that for SRAM plus all
the interface logic (address decode, etc.)).
So, could be integrated as separate chips onto 1 carrier:
Looking at: https://www.apple.com/v/mac/m1/a/images/overview/chip__fffqz3ljssi2_large.jpg
That looks like 2 memory modules integrated onto the same carrier as the processor portion to the left.
IAC: we'll see in an M1 Mac if the memory "spec" is listed in the system information. I look forward to your screenshot.
On 2020-11-14 13:47, nospam wrote:
An you think they simply recompiled the 68000 code for Intel Are ou
really that daft?
do you really need to ask?
Argument was made that Adobe had to rewrite large parts because they
were in 8086 assembly. I counterred that Adobe already had multi platfor support in the past.
So they can rewrite parts for ARM if they want to.
But it does show that it isn't just a simple recompile.
And Assembler, by definition, generates opcodes that match your code
both in nature and order. No optimizatiosn possible.
In message <D5WrH.797928$eN2.187141@fx47.iad> Alan Browne <bitbucket@blackhole.com> wrote:
On 2020-11-14 13:34, Lewis wrote:
Seems like it. The M1 is not an "existing type" it is a new chip
designed by Apple and made to their design. it is not being assembled out >>> of other bits.
Those elements can come from different designers(companies) with the
data for the design transferred to Apple to integrate into their overall
design by specification.
No, I don't think that is correct. The SoC is entirely Apple design.
Apple claim "16 billion transistors" for the M1. That can't possibly
represent the entire CPU + 8 GB or 16 GB of memory. (8 GiB would take a
minimum of 64B transistors for a DRAM and 6 times that for SRAM plus all
the interface logic (address decode, etc.)).
The 16 billion transistors is for the CPUs specifically, not for the
entire M1. but how the RAM is integrated into the Soc? Sure, maybe those components are sourced separately..
So, could be integrated as separate chips onto 1 carrier:
Looking at:
https://www.apple.com/v/mac/m1/a/images/overview/chip__fffqz3ljssi2_large.jpg
That looks like 2 memory modules integrated onto the same carrier as the
processor portion to the left.
It does. We'll know more when someone scrapes an M1 and takes an
electron microscope to it, I suppose.
Well, that is the point. Hand code in assembler so that every possible instruction cycle is optimal.
Adding to that you have no clue what translators may be doing to
optimize code.
For example they could easily decide to remove a bunch
of pushes onto the stack because more registers are available than the original target.
This is why Digital died.
Yep. They are dead. Get over it.
Not at all. I probably have more experience with hardware and assembler
on a range of processor types than pretty much everyone here
Which, as I point out elsewhere, is almost certainly in HOL. High speed
I/O is most often via some variant of DMA.
Assembler allows the designer to carefully optimize every tiny step and
if desired model every machine cycle, etc.
Eventually. Honestly, "net year" is lightning speed for Adobe.
Omni, all app on day one for M1. Affinity, all apps on M1 on one. Adobe
and Microsoft? Eh, some day next year probably. Google? 2027 for
anything not Chrome.
On 2020-11-14 18:26, Lewis wrote:
Eventually. Honestly, "net year" is lightning speed for Adobe.
Adobe would have been aware of Apple's move to ARm for some time, well
before WWDC announcement. Adobe has also ported Photoshop to IOS/iPAD
OS, so some of that work may already have been done.
What surprises me is that Photoshop was mentioned, not Première or After Effects which are facr more complex software in terms of hardware
interaction because they, at least on Wintel with CUDA GPSU will make
use of the GPUs a lot.
Omni, all app on day one for M1. Affinity, all apps on M1 on one. Adobe
and Microsoft? Eh, some day next year probably. Google? 2027 for
anything not Chrome.
The keynote spoke at great length of its laptops for video and photo
editing. It didn't focus on those laptops being use for workd processor
or email.
If the keynote focuses on the very tasks handled by Adobe,
then if Adobe isn't there, it's a problem.
(Especially since at WWDC they demoed Adobe software running translated, which shows they place importance on Adobe software.
Adobe would have been aware of Apple's move to ARm for some time, well
before WWDC announcement.
Adobe has also ported Photoshop to IOS/iPAD
OS, so some of that work may already have been done.
What surprises me is that Photoshop was mentioned, not Première or After Effects which are facr more complex software in terms of hardware
interaction because they, at least on Wintel with CUDA GPSU will make
use of the GPUs a lot.
On 2020-11-14 15:50, Alan Browne wrote:
Well, that is the point. Hand code in assembler so that every possible
instruction cycle is optimal.
Jave you coded on Alpha? Have you coded on Itanium ? VAX ?
The Macro (VAX assembly langage) *compiler* for IA64 produced
faster/more efficient code than hand coding native IA64 assembler
becauise the LLVM/compilets on Ianiium spent the time to order and block
the operations properly to allow Itanic chips to run fast.
Doing the work native on IA64 would require you not only translate yoru
idea into individual opcodes, but also know what type of operations to
do in what order and insert the IA64 specific operations to tell the
chip which operatiosn depnds on which one.
Adding to that you have no clue what translators may be doing to
optimize code.
Apple has given sufficient hints on Rosetta2, namely that all system
calls and linked to a special library that accepts the call with Intel argumant passing mechanism and then issue corresponding call to the
"real" routine with ARM argument passing standard.
This means the translator really only translates existing function
without undestanding what it does. Optimizing is much easier at higher
level because the concept of the loop etc are understood by the compiler.
For example they could easily decide to remove a bunch
of pushes onto the stack because more registers are available than the
original target.
A language like Postscript is based on a stack, as is a reverse polish calculator. That stack is part of the logic, not just some means to deal
with shortage of registers. A translator cannot know if you are using
the stack as temporary storage or whether it is an integral part of your logic. The translator must maintain functionality.
A compiler generating code for x86 may decide to use stack mechanism to
store a value, and the same code, with teh same compiler targetting ARM
may use a register. But that is a decision made by compiler who
understand the desired goal of the sourcxe code.
A translator of already compiled binary code doesn't. If it sees use of stack, it doesn't know whether it was meant as temporary storage, or if
it was truly meant as a LIFO storage logic desired by the program.
This is why Digital died.
Yep. They are dead. Get over it.
Not sure where you got that quote, bit is was not me who said this in
this thread.
Not at all. I probably have more experience with hardware and assembler
on a range of processor types than pretty much everyone here
Simple "embedded device" processors tend to not have very fancy logic
and it is straighforward to code for them. Once you get into high
performnce processors (or the Itanic where Intel tried high
performance), it gets verry messy because of how a processor reacts to instructions.
When you code for a processor that has faults when you tru to access
memory that isn't quadword aligned (64 bits), your fancy assembler code
that ran well on a less complex CPU suddently runs like molasses even
though that processor is supposed to be high performance. This is
something that won't happen with higher level labguage because the
copiler and LLVM know to align all memory access to a quadword to avoid
this and this is done automatically for you. so if you need the 3rd
byte, it will fetch 8 bytes from memory into a register and do the
sfifts to get the byte you want to avoid the memory fault.
[See AAA above]Mezei wrote, and snipped in an attempt to dodge the facts:
In the case of OS-X, much already exists from IOS, so much could be
re-used, but there is still code needed for the new
thunderbolt/USB-4 drivers and all the variants attached to it,
including ethernet >>>drivers attached to the new thunderbolt/USB-4
IO interface.
Which, as I point out elsewhere, is almost certainly in HOL. High speed
I/O is most often via some variant of DMA.
Photoshop is not low level device driver. Most of a device driver is
now at higfher level labguage with only the very lowwest level in
assembler where you only do a few instructions.
Assembler allows the designer to carefully optimize every tiny step and
if desired model every machine cycle, etc.
"allows" is the keyword. The problem is that it requires you have
intimate knowledge of the whole architecturure to know what combinations
of OP codes you can use and in what order and know how the CPU will
pipeline them into different instriction prefetch etc.
When you are dealing with simplerembedded device CPUs, life is much
simpler and you focus on optimizing logic because every assembvler instruction is executed sequentially anyways.
In message <2C1sH.110171$4d1.92234@fx09.iad> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:<snip>
On 2020-11-14 18:26, Lewis wrote:
Eventually. Honestly, "net year" is lightning speed for Adobe.
Adobe would have been aware of Apple's move to ARm for some time, well
before WWDC announcement. Adobe has also ported Photoshop to IOS/iPAD
OS, so some of that work may already have been done.
And yet, Adobe is slow. Adobe is always slow. Their sloth has nothing to
do with anything or anyone who is not Adobe.
What surprises me is that Photoshop was mentioned, not Première or After
Effects which are facr more complex software in terms of hardware
interaction because they, at least on Wintel with CUDA GPSU will make
use of the GPUs a lot.
Photoshop is Adobe's #1 product.
Irrelevant to x86 / ARM transition and, read the news: Alpha is OLD and dead technology.
The most recent Itanium iteration had no improvement
than clock speed. And that was in 2017. That is the end of that
product. It's dead Jim.
And yes, I've coded on VAX VMS, though exclusively HOL
For lazy assembler writers, sure. Don't forget, at heart, the compiler writes machine instructions that are entirely expressible in assembler.
Thus a good assembler programmer would do fine.
As I've explained several times, writing good efficient code is the goal
of writing assembler.
QUOTE
Rosetta 2 can convert an application right at installation time,
effectively creating an ARM-optimized version of the app before you’ve opened it.
I was referring to stack machine call conventions for parameter passing
and saving return addresses, registers, etc. You're referring to an implementation abstraction.
An RPN calculator, in HOL code, emulates a calculator stack in vars
(usually a linked list of some kind). This is not the same as the
machine stack, but instead an abstraction of a calculator stack usually implemented in a HOL such as C, Fortran, Pascal, etc.
Properly written and tested assembler code will avoid such faults.
Further, align pragmas are very present in assembler (and have been for
a very long time going back) if one wants speed over storage. Just
design trade decisions.
I was replying to your I/O points that you snipped out and that I
restored above.[AAA]. Again: device drivers are less and less in
assembler and more and more HOL.
A good programmer should have such knowledge - as I've pointed out elsewhere.
Assembler is not worth the cost in 99.99% of cases. Adobe, who cater to
a huge audience including very high end photography and marketing departments want to not only do the most, but do it fast.
Intel's x86 has "alphas Inside". AMD has "Alphs Inside". Apple's Ax
chips have Alpha inside.
Intel's x86 has "alphas Inside". AMD has "Alphs Inside". Apple's Ax
chips have Alpha inside.
On 2020-11-15 11:56, Alan Browne wrote:
Was was very very CISC, but because of that, was also vbery simple in
terms of how it processed instructions. This is whty Digital moved to
RISC where it could then work on simpler instructions that could easily
be opto9mied and huge efficiency gains. Those optimizations is what
makes coding in Assember a lot harder if you want to be efficient.
For lazy assembler writers, sure. Don't forget, at heart, the compiler
writes machine instructions that are entirely expressible in assembler.
Thus a good assembler programmer would do fine.
The compiler and now LLVM are intimate with the target CPU and will do optimiuzations that a organized Assembler program won't do because it
would become inreadable with operations i different order than your
logic requires.
As I've explained several times, writing good efficient code is the goal
of writing assembler.
This is old thinking because CPUs have gotten very complex under the
hood on how the process opcodes. Assembler is required for very low
level stuff (drivers, hardware interface) and if you need to use
instructions such as encryptioN/copmpression tyat are in the CPU but not accessible from high level language. (and at that, the code snippet is
very short, taking argumenst, issuing the opcode and then returning).
QUOTE
Rosetta 2 can convert an application right at installation time,
effectively creating an ARM-optimized version of the app before you’ve
opened it.
The binary being translated has been optimised for x86. Rosetta 2 will translate to replicate x86 operations with a or multiple ARM
instructions. But it will not optmize, reorder or regroup opcodes to
make full use of how Apple implemented ARM.
This is why an application compiled for ARM will outperform the same appliction compiled for x86 and then translated to ARM.
I was referring to stack machine call conventions for parameter passing
and saving return addresses, registers, etc. You're referring to an
implementation abstraction.
At run time, the CPU does not know if you are pushing something on the
stack for the purposes of building an argument list for subsequent call
to subroutine (which for it, is a mere "branch") or whether you are
pushing something something on the stack because you are implementing a
LIFO buffer in your logic which must not be thinkered with.
the CPU has no idea when you will be popping items from the stack, nor
does it know how many items will be popped from the stack when the next subroutine is called.
And do not forget that calling any system service will get you to a
jacket subroutine which will process your Intel-format argument line,
built an ARM formal argument list and then call the system service for
you. So the translator cannot willy nilly change push and pops into
register storage operations.
An RPN calculator, in HOL code, emulates a calculator stack in vars
(usually a linked list of some kind). This is not the same as the
machine stack, but instead an abstraction of a calculator stack usually
implemented in a HOL such as C, Fortran, Pascal, etc.
A RPN calculator written in Assembler will make full use of the stack.
And the varous "stack" operations available from highler level languages
will make use of them as well.
Properly written and tested assembler code will avoid such faults.
Further, align pragmas are very present in assembler (and have been for
a very long time going back) if one wants speed over storage. Just
design trade decisions.
Align pragmas align a variable. But if you need the 3rd byte of a 4 byte variable, your assembler will be quite different if you run on a machine
that lets you access any byte, vs one that required only
quadword-aligned accesses. (at which point, you load value in register
and do shifts to get your 3rd byte).
I was replying to your I/O points that you snipped out and that I
restored above.[AAA]. Again: device drivers are less and less in
assembler and more and more HOL.
And for exactly the reasons I mentioned. What is left is truly the very
low level stuff.
=
A good programmer should have such knowledge - as I've pointed out
elsewhere.
So I take it that you are like nospam and lewis and claim to have
intimate knowledge of how Apple implemented ARM instriuctions, what sort
of logic its CPUs have in terms of instruction processing, pr-fetching, parralel instruction decoding, pr-loading of values, branch prediction etc?
Assembler is not worth the cost in 99.99% of cases. Adobe, who cater to
a huge audience including very high end photography and marketing
departments want to not only do the most, but do it fast.
Adobe products have to respond to a large variety of variants wvene
within the 8086 family. They likely have high level labnguage
implementation of logic, but if running on a a CPU that supports
instriction Z, will instead branch to a small assembler routine that
uses the opcode available on that CPU.
And I have to assume that Apple provided that info to Adobe under NDA a
long long time go.
In article <miwsH.528513$RY8.414225@fx48.iad>, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
Intel's x86 has "alphas Inside". AMD has "Alphs Inside". Apple's Ax
chips have Alpha inside.
nonsense.
And, as mentioned, the ARM-64 is pretty CISCy as are most formerly RISC processors have evolved over time.
Out of order ops are equally implementable by writing assembler.
No it is not old thinking. You resort to assembler because the compiler
is not doing as well as hand written machine code.
And (again) most drivers are actually in HOL. Not assembler. Because
of all sorts of needs from portability to maintenance
You have no clue at all how Rosetta 2 works.
Do you believe that Apple
are working at your coarse level of unpracticed understanding or that perhaps they are making R2 really shine with a sophisticated conversion process - one that takes place at install time especially?
For most implementations the translation will be a one time (on install
of the x86 code) event. That one time event allows for all sorts of cleverness.
You don't seem to understand that the CPU stack is not the stack used in
the abstraction of a thing like an RPN calculator.
Again: implementation of RPN stack abstraction ≠CPU stack.
The point of an align pragma is so the next declared variable begins on
the align divisor address. Properly accessing that variable results in
a correct store or load.
Every processor I've worked on does the shifting automatically (at the
cost of a few machine cycles) if the word is not aligned.
Not in Adobe's case it would appear. They are doing some core
functionality in assembler in order to have higher performance.
I have intimate knowledge of real time programming in various assembler languages, though not ARM. Looking at the ARM architecture there is
nothing esp. daunting, and of course going forward from an architecture
with 16 general purpose x 64b registers to one with 29 x 64b GP
registers doesn't make anything harder - quite the opposite.
Conclusion: you don't know much about machine level programming. Your silly RPN example is clear evidence of that (can't discern between the
CPU stack and an RPN program stack abstraction).
The M1 is blazing fast for a variety of reasons from the CPU design
(always getting better) to an optimized use of memory ("unified")
And I expect that the M2 and on will quite fantastic with even higher
core counts appropriate to iMacs, higher end minis and laptops and "pro" machines.
No it is not old thinking. You resort to assembler because the compiler is not doing as well as hand written machine code.
C, Fortran and COBOL , on older plaforms gnerated very efficient code.
On newwer platforms, tend to generate more efficient code due to optimizations by the compiler.
C++ has a few more layers of abastractions, but can also generate very efficient code, as with Apple's SWIFT. This is because the optimizatiosn
done by the compiler and then by LLVM make maximum use of the chip, and
the old concept of only assembly being fast is gone.
And (again) most drivers are actually in HOL. Not assembler. Because
of all sorts of needs from portability to maintenance
hardware drivers still need some assembler at lowest level to interface
with the hardware.
Higher level drivers can be in C or other.
Consider also that OS-X is ARM native form day 1, comtrary to the 68K to Power PC which kept many parts as 68K until finally converted. So there
is less of a need to make a super duper efficient translator.
You don't seem to understand that the CPU stack is not the stack used in the abstraction of a thing like an RPN calculator.
The whole point of a CPU providing a stack is so it could be used. You
have no right to state that it is only used for argument passing.
Again: implementation of RPN stack abstraction ‚ CPU stack.
Are you saying it is illegal to use the stack for such an app?
On which CPU/OS is it illegal ?
The point of an align pragma is so the next declared variable begins on the align divisor address. Properly accessing that variable results in
a correct store or load.
You missed the point. Your variable may be aligned, but if the variable
is a single byte, the available assembly operation might force load 8
bytes into the register. So you then have to play with shifts within the register to get the one byte places in the leest significant bits of the register. (and do the shisfst with awareness of sign implementation on
that platform).
On a compiler, this is done for you in the most efficient way and the compiler may decide dto put many 1 byte variables together so one load
from memory allows access to any of the variable from register.
Every processor I've worked on does the shifting automatically (at the cost of a few machine cycles) if the word is not aligned.
For Itanic, it was an acual fault for the early versions. Heavy
performance penalty. The fault code would then pickup the 8 bytes and
extract what you needed from it for you. Whe Intel designed the chip,
they though compilers would take care of this. But it turns out not all computing is scientific, and the business applications on those large machines tended to treat charactersas strings and not numbers whene processing a client record. So even COBOL ended up generating terrible performance.
Not in Adobe's case it would appear. They are doing some core functionality in assembler in order to have higher performance.
I doubt there is much in Assembler code. Likely very small routines that
make use of 1 opcode to encode/decode/copmpress/decompress a block, with
a high level routine doing the same work sitting on the siote for when
app is execured on a CPU that doesn't have that extra instruction.
The M1 is blazing fast for a variety of reasons from the CPU design (always getting better) to an optimized use of memory ("unified")
Oh come on now. "unified memnory" is just marketing bullshit. Apple
hasn' conformed memory type or speed on the M1, it is only speculation
that it is the same as on the Intel model (the Lo power DDR4).
Real benchmarks should start popping up soon. Ones that last a few
minutes, enough to test thermal performance.
And I expect that the M2 and on will quite fantastic with even higher
core counts appropriate to iMacs, higher end minis and laptops and "pro" machines.
Only time will tell how Apple will scale its Axx chips to the Mac line
and what will become of the Mac Pro.
Omni, all app on day one for M1. Affinity, all apps on M1 on one. Adobe
and Microsoft? Eh, some day next year probably. Google? 2027 for
anything not Chrome.
The keynote spoke at great length of its laptops for video and photo
editing. It didn't focus on those laptops being use for workd processor
or email. If the keynote focuses on the very tasks handled by Adobe,
then if Adobe isn't there, it's a problem.
(Especially since at WWDC they demoed Adobe software running translated, which shows they place importance on Adobe software.
On 2020-11-16 14:01, Alan Browne wrote:
And, as mentioned, the ARM-64 is pretty CISCy as are most formerly RISC
processors have evolved over time.
So can you please describe
| Sysop: | Gate Keeper |
|---|---|
| Location: | Shelby, NC |
| Users: | 790 |
| Nodes: | 20 (0 / 20) |
| Uptime: | 39:03:22 |
| Calls: | 12,115 |
| Calls today: | 5 |
| Files: | 5,294 |
| D/L today: |
72 files (9,959K bytes) |
| Messages: | 564,927 |
